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COMPUTER SOFTWARE ADDENDUM 

Attached hereto is a compact disc containing computer software and 
data including executable programs, scripts, and database management 
system tables that are used to implement the systems and methods provided by 
the present invention. More particularly, the attached compact disc contains 
software and data used to implement at least two distinct applications 
comprising the systems and methods provided by the present invention; such 
two distinct applications include a broad-based, general use energy 
management system (referred to as the Energy Management System "EMS"), 
and a limited user/function restricted application (referred to as the Producer 
Control Center "PCC") intended for use by fuel producers needing access to 
centrally stored and managed fuel deal data. Such material is protected by the 
Copyright Laws of the United States (17 U.S.C. § 101, et seq.) and may not be 
copied without the express, written authorization of the copyright holder 
(Highland Energy Corporation). Copyright © 2001, Highland Energy 
Corporation. All Rights Reserved. 

BACKGROUND OF THE INVENTION 
Field of the Invention 

The present invention relates to systems and methods used to facilitate 
pricing, sale, and distribution of fuel to a customer. More particularly, the 
present invention is directed to automated systems and methods that are used 
to price fuels such as natural gas, oil, gas, other petroleum based fuels, etc., to 
facilitate commodity sales of such fuels, and to distribute such fuels to 
customers, and to track and report sales and distribution related data. 



Description of the Related Art 

Fuel sales and distribution systems and techniques are well known. 
Everyday millions of fuel sale contracts are completed in the U.S. and abroad. 
Fuels produced by a range of producers are transported over many modes of 
transportation (e.g., gas pipelines, etc.) to ultimately arrive at an intended 
destination. The steps involved in pricing fuel, selling a reserve, storing 
reserves, and ultimately transporting purchased fuel involve many parties 
including producers, agents, brokers, other middlemen and, ultimately, end 
customers. All of these parties have their own unique ways of doing business, 
reporting sale and purchase data, and collecting and paying against agreed 
upon contracts. 

Unfortunately, many of the steps and processes carried out to facilitate 
fuel sales and distribution are archaic, inefficient, and, often, paper-based. 
Such inefficient ways of doing business cause many parties to engage large 
teams of personnel to manage the intricate details often involved in fuel sale 
and distribution. Fuel deal pricing provides a good example of the inefficiencies 
involved in moving large volumes of natural gas and other fuels. 

Typically, pricing fuel deals in the natural gas arena involves manual 
processes related to gathering fuel index rates, manually computing sales 
prices across a multitude of fuel sales deals, laboriously factoring in 
transportation and other tangential costs, and managing for fuel overages and 
short falls often associated with transportation anomalies, etc. These 
processes typically involve the efforts of large teams of personnel within 
organizations who are required to constantly monitor sales deals, set pricing 
limits for sales people, and track and record fuel deal progress. 

While many systems have been developed to facilitate sale and 
distribution of fuel and other products, commodities, and services in general, no 
systems developed to date can effectively management the volume of 
transactions among a wide array of parties to efficiently and effectively get fuel 
from one place to another. Moreover, existing systems have heretofore not 
been able to facilitate pricing practices that factor in past fuel deal data across a 



multitude of prior fuel deals to better drive profit margins in the commodities and 
brokerage fields. 

Accordingly, there exists a serious need to provide systems and methods 
that enable centralized location and management of fuel deal data, provide for 
application of pre-determined pricing techniques based on such fuel deal data, 
facilitate broad-based reporting based on such centrally stored fuel deal data to 
drive better business practices for parties to fuel deals, and increase 
productivity and make more efficient fuel sale and distribution practices. The 
present invention squarely addresses such a need and provides a new and 
improved systems and methods for facilitating fuel sale and distribution. 

SUMMARY OF THE INVENTION 

The present invention solves the problems mentioned above with regard 
to prior systems and methods used to facilitate sale and distribution of fuel to a 
customer. By squarely addressing the limitations of prior systems and 
methods, the present invention provides new and improved systems and 
methods that permit a wide array of users to broadly access a central data store 
to create and manage fuel deal data. Such new and improved systems and 
methods further permit the inclusion of pricing processes into existing business 
processes that are based on prior fuel deal data and which take into account 
prior prices charged across collections of prior fuel deal contracts. 

Accordingly, the present invention provides new and improved systems 
and methods for facilitating sale and distribution of fuel to a fuel customer. 
Such systems and methods include and involve a server facility configured to 
store fuel deal data and to process such fuel deal data to automatically 
generate pricing data based on the fuel deal data and in accordance with a pre- 
determined pricing technique. The system and method also include and involve 
a client facility that is coupled to the server facility via an electronic data network 
and which is configured to permit a user to enter such fuel deal data and to 
cause the server facility to store and process the fuel deal data to generate the 
pricing data. As such, fuel may be sold and distributed to a fuel customer via a 



fuel distribution system based on the fuel deal data and the automatically 
generated pricing data. 

BRIEF DESCRIPTION OF THE DRAWINGS 

The present invention is described in detail below with reference to the 
following drawing figures, of which: 

FIG. 1 is a timing diagram that depicts process flows within a business 
process that facilitates sale and distribution of fuel to customers in accordance 
with a preferred embodiment of the present invention; 

FIG. 2 is a system diagram in which client systems can access server 
system(s) to facilitate sale and distribution of fuel to customers in accordance 
with the business process illustrated in FIG. 1; 

FIG. 3A is an entity relationship diagram that depicts data relationships 
among tables and corresponding table entries used to implement the systems 
that carry out the business process illustrated in FIG. 1; 

FIG. 3B is another entity relationship diagram that depicts data 
relationships among tables and corresponding table entries used to implement 
the systems that carry out the business process illustrated in FIG. 1; 

FIG. 3C is another entity relationship diagram that depicts data 
relationships among tables and corresponding table entries used to implement 
the systems that carry out the business process illustrated in FIG. 1; 

FIG. 3D is another entity relationship diagram that depicts data 
relationships among tables and corresponding table entries used to implement 
the systems that carry out the business process illustrated in FIG. 1; 

FIG. 3E is another entity relationship diagram that depicts data 
relationships among tables and corresponding table entries used to implement 
the systems that carry out the business process illustrated in FIG. 1 ; 

FIG. 3F is another entity relationship diagram that depicts data 
relationships among tables and corresponding table entries used to implement 
the systems that carry out the business process illustrated in FIG. 1; 



FIG. 3G is another entity relationship diagram that depicts data 
relationships among tables and corresponding table entries used to implement 
the systems that carry out the business process illustrated in FIG. 1; 

FIG. 3H is another entity relationship diagram that depicts data 
relationships among tables and corresponding table entries used to implement 
the systems that carry out the business process illustrated in FIG. 1; 

FIG. 31 is another entity relationship diagram that depicts data 
relationships among tables and corresponding table entries used to implement 
the systems that carry out the business process illustrated in FIG. 1; 

FIG. 3J is another entity relationship diagram that depicts data 
relationships among tables and corresponding table entries used to implement 
the systems that carry out the business process illustrated in FIG. 1 ; 

FIG. 3K is another entity relationship diagram that depicts data 
relationships among tables and corresponding table entries used to implement 
the systems that carry out the business process illustrated in FIG. 1; 

FIG. 3L is another entity relationship diagram that depicts data 
relationships among tables and corresponding table entries used to implement 
the systems that carry out the business process illustrated in FIG. 1 ; 

FIG. 3M is another entity relationship diagram that depicts data 
relationships among tables and corresponding table entries used to implement 
the systems that carry out the business process illustrated in FIG. 1 ; 

FIG. 3N is another entity relationship diagram that depicts data 
relationships among tables and corresponding table entries used to implement 
the systems that carry out the business process illustrated in FIG. 1; 

FIG. 4A is another screen shot of a data processing application running 
within a client system to facilitate at least some of the operations carried out to 
effect the business process illustrated in FIG. 1; 

FIG. 4B is another screen shot of a data processing application running 
within a client system to facilitate at least some of the operations carried out to 
effect the business process illustrated in FIG. 1; 



FIG. 4C is another screen shot of a data processing application running 
within a client system to facilitate at least some of the operations carried out to 
effect the business process illustrated in FIG. 1; 

FIG. 4D is another screen shot of a data processing application running 
within a client system to facilitate at least some of the operations carried out to 
effect the business process illustrated in FIG. 1; 

FIG. 4E is another screen shot of a data processing application running 
within a client system to facilitate at least some of the operations carried out to 
effect the business process illustrated in FIG. 1 ; 

FIG. 4F is another screen shot of a data processing application running 
within a client system to facilitate at least some of the operations carried out to 
effect the business process illustrated in FIG. 1; 

FIG. 4G is another screen shot of a data processing application running 
within a client system to facilitate at least some of the operations carried out to 
effect the business process illustrated in FIG. 1; 

FIG. 4H is another screen shot of a data processing application running 
within a client system to facilitate at least some of the operations carried out to 
effect the business process illustrated in FIG. 1; 

FIG. 41 is another screen shot of a data processing application running 
within a client system to facilitate at least some of the operations carried out to 
effect the business process illustrated in FIG. 1; 

FIG. 4J is another screen shot of a data processing application running 
within a client system to facilitate at least some of the operations carried out to 
effect the business process illustrated in FIG. 1; 

FIG. 4K is another screen shot of a data processing application running 
within a client system to facilitate at least some of the operations carried out to 
effect the business process illustrated in FIG. 1; 

FIG. 4L is another screen shot of a data processing application running 
within a client system to facilitate at least some of the operations carried out to 
effect the business process illustrated in FIG. 1; 



FIG. 4M is another screen shot of a data processing application running 
within a client system to facilitate at least some of the operations carried out to 
effect the business process illustrated in FIG. 1; 

FIG. 4N is another screen shot of a data processing application running 
within a client system to facilitate at least some of the operations carried out to 
effect the business process illustrated in FIG. 1; 

FIG. 40 is another screen shot of a data processing application running 
within a client system to facilitate at least some of the operations carried out to 
effect the business process illustrated in FIG. 1; 

FIG. 4P is another screen shot of a data processing application running 
within a client system to facilitate at least some of the operations carried out to 
effect the business process illustrated in FIG. 1; 

FIG. 4Q is another screen shot of a data processing application running 
within a client system to facilitate at least some of the operations carried out to 
effect the business process illustrated in FIG. 1; 

FIG. 5A is a flow chart that illustrates the operations carried out to effect 
a pricing technique and, in particular, one that effectuates a weighted average 
sales price for fuel deals in accordance with a preferred embodiment of present 
invention; and 

FIG. 5B is the conclusion of the flowchart started in FIG. 5A. 

DETAILED DESCRIPTION OF THE 
PREFERRED EMBODIMENTS 

The present invention is now described in detail with regard to the 
drawing figures that were briefly described above. 

The systems and methods described herein are illustrative of the exemplary 
system implemented by way of computer software within a networked data 
processing environment and which is contained within multiple files housed on 
the compact disc that is appended to this patent document. Accordingly, the 
discussion that follows refers to such an exemplary system and those skilled in 
the art are encouraged to review such appended software in the context of fuel 



deal management for a complete understanding of the present invention. As 
noted at the beginning of this patent document, the material contained on the 
attached compact disc is protected by the Copyright Laws of the United States 
(17 U.S.C. § 101, et seq.) and may not be copied without the express, written 
authorization of the copyright holder (Highland Energy Corporation). Copyright 
©2001, Highland Energy Corporation. All Rights Reserved. 

Referring now to FIG. 1, . depicted therein is a timing diagram 
corresponding to the business process carried out within an organization to 
facilitate sale and distribution of fuel to a customer and which may be set up to 
utilize the systems and methods provided by the present invention. In 
particular, FIG. 1, illustrates a monthly or periodic business process involving 
several phases of operation that are carried out by the systems and methods 
provided by the present invention including, but not limited to: an availability 
phase, a bidding phase, a nominating (e.g., gas pipeline nominations, etc.) and 
routing phase, a third party and sanctioned sales period, a pricing period, an 
invoicing period, and an accounting period. Together, these periods make up 
what is referred to herein as a MONTH OF FLOW PROCESS (MFP). The MFP 
is described next to further illustrate the business operations that are handled 
by the systems and methods provided by the present invention. 

THE MONTH OF FLOW PROCESS (MFP) 
Availability Period 

During the availability period of the month of flow process, equity 
contracts for sale and distribution of fuel (those that need to roll from month to 
month) are established for the next month. These purchase deals define the 
anticipated volumes by well/meter for each producer. The status for the 
production month needs are set to 'Availability' at this point. Then, 
correspondence is transferred (via fax, email and phone conversations) to the 
various operators/producers in order to confirm the anticipated volumes to be 
produced. 



The anticipated production volume for an entire well/meter is then 
entered into the system. An entitlement and makeup percentage is used to 
indicate how much of this volume is actually available to be marketed 
(represents the owner interest in the production of the well/meter). New deals 
are setup on the system to represent the new month's purchases. The package 
description is utilized to assist with easy recognition of volumes, price, etc. 
(used for identification purposes only). There is a process built within the 
system to automate the propagation of new deals to the next month (first time 
into a new month will automatically generate entries for the new month with 
zero volume amounts). The actual volume stored on the system (at this point) 
is zero. Only the nominated volumes contain the expected volumes for the 
production month. These 'nominated" volumes are equal to the estimates 
provided by the producers and entered into the system during this part of the 
month of flow. The primary area of the system utilized is the 'Availability' 
functions (off the system's main menu.) 

Bid Week Period 

During the bid week of the month of flow process, buyers are found for 
the volumes that were made available through the availability step described 
above. The status of the production month of the system needs is set to 'Sales" 
at this point. By setting the status to bales' all of the price indices will be 
initially populated and 'seeded' with zero values. Each of the sales is confirmed 
by a dealmaker and is written up on a deal log sheet. These deal log sheets 
reflect the pipe/field, meter/well, company, contract, volume, and pricing 
instructions to support the sale. Prior to completing a deal, the dealmaker will 
work closely with the volume control group to ensure that appropriate volumes 
will be available at the well/meter of sale. The dealmakers then complete the 
deal log sheet entries for the sale and they are transferred to the volume control 
group for deal creation and entry into the system. Most of the volumes sold 
during this particular phase are for the equity purchase deals created during the 
availability period. 



Nominating and Routing 

During the nominating and routing period of the month of flow process, 
the volumes to support the sales are routed from the producer's well/meters to 
the sales wells/meters (primarily to pooling points or field tanks). This process 
occurs throughout the entire month. When the volumes are routed to specific 
pool wells/meters, allowances are automatically made by the system for fuel, 
gathering and transport costs. These costs will net down the actual available 
volumes that can be applied to the sales deals. When volumes are routed to a 
pool/tank then these volumes reflect as Transport Out volumes 1 . The volumes 
then show up as "Transported In 1 (net fuel) on the receiving meter/well within 
the system. The primary area with the System utilized during this process is the 
"Route Volume" menu option within the Routing module (main menu selection 
of 'Routing* on the System. 

Third Party Deals and Sanctioned Sales 

During the Third Party Deals and Sanctioned Sales of the month of flow 
process, the dealmakers complete the third party deals. These deals are 
typically setup where a specific purchase deal (non equity type) is made to 
support a specific sales deal. These types of deals will usually have a specific 
price agreement and volume associated with them. Sanctioned sales represent 
sales from equity volumes with specific terms (prices, volumes, etc.) to specific 
sales meters. A sales price for a specific volume is set in advance of the 
production month with these types of deals. All third party deals are excluded 
from Weighted Average Sales Price (WASP) calculations as discussed below 
with regard to FIGS. 5A and 5B (each third party purchase volume exists within 
its own WASP pool ('None')). All sanction sales deals are included within the 
WASP calculation but EACH combination sanction sales (purchase-to-sale) will 
utilize a 'Dedicated' WASP pool during the calculation. In this way, sanction 
sale costs etc. PLUS netback percentages can be applied. All equity deals 
combined with the 'Common' WASP pool where costs and prices are 
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aggregated by meter/well based on volume weightings. All deals actually go 
through the calculation in order determine margins. However, the calculation 
has been setup to ensure that third party, sanctioned sale and equity pools are 
calculated without interfering with each other. 

Pricing 

During the pricing period of the month of flow process, all monthly index 
based prices are entered immediately when published. These are usually 
entered just before the beginning of the production month. Daily prices are 
keyed or otherwise entered throughout the month as they are received. When 
deals are setup the Pricing' function within the System is used to actually 
calculate a price for the deal ('Price' tab on deal detail screen). Each evening, 
for example, the Price All Deals' function of the System is started. This 
particular function will re-price all deals for the entire month (Price + WASP 
calculations). For months in the 'Sales' phase, the nominations are re-priced 
and recalculated. For months in the 'invoiced' phase, the pipe/field actuals are 
re-priced and recalculated. In addition, to this periodic process, an option exists 
within the System to price production months throughout a day, for example. 
Below, with reference to FIGS. 5A and 5B, the details related to fuel deal pricing 
are described. The ability of the present invention to incorporate a pricing 
technique such as one that is predetermined and implemented as a modular 
component of a larger software system, represents a significant point of novelty 
to which the present invention is directed. 

Invoicing 

During the invoicing period of the month of flow process, invoices for all 
of the sales for the previous month are produced. This represents the final step 
of the month within the system. All marketing individuals directly involved with 
the system for the month (controllers, dealmakers, etc.) are informed that the 
month is closing out and that invoices are now being produced. The status for 
the production month is changed to 'Invoiced'. A final nomination calculation is 



automatically done with the status updated. Accounting is then notified that the 
month has been completed. Invoicing reports are then run for the month and 
sent to the buyers by an accounting group, for example. Additional reports may 
be run (Sales By Pipe/Field, Purchase By Producer, Balancing Reports, 
Pipeline Statement Comparison Reports, etc.) by the accounting group for 
historical reference and reconciliation. 

Accounting 

During the accounting period of the month of flow process, an accounting 
group creates a revenue and journal entry feed to track receivables within an 
automated accounting system. This feed is created directly out of the system. 
Pipe/Field statements begin appearing beginning as early as the 15 th of the 
month. These statements represent volumes (by well/meter) for the previous 
month. Each accounting analyst is responsible for a specific set of pipe/fields. 
The volumes from these statements are entered as actuals into the system. A 
copy of the Pipe/Field statements are sent to the controllers for sign off. 
Accounting analysts then balance all of the purchase meter routing information 
for their respective pipe/fields. Accounting analysts then balance all of the 
sales meters for their respective pipe/fields. Accounting analysts then adjust 
any route volumes that cross pipe/fields to ensure interconnect balances are 
synchronized with pipe/field statements. Reconciliation and voucher reports 
can be run immediately after the production month is promoted to 'Accounting* 
phase (meaning accounting is finished with the month). These reports can then 
be sent to producers and/or entered into to accounting system. 

AN EXEMPLARY SYSTEM 

Referring now to FIG. 2, depicted therein is a diagram of an exemplary 
system in which client systems can access server system(s) to facilitate sale 
and distribution of fuel to customers in accordance with the business process 
(MFP) illustrated in FIG. 1. In particular, system 100 includes both server(s) 
102 and client systems 104. Additionally, a database management system and 
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corresponding data store 106 (hereinafter data store 106) is used to store fuel 
deal data and programs. Servers 102 are configured to be accessed via wide 
area network connections such as those facilitated via the Internet using open 
standards based protocols. Client systems 106 are configured with software 
contained on the appended compact disc to access servers 102 to engage in 
fuel deal operations such as those described with reference to the month of flow 
process (MFP) discussed above with regard to FIG. 1 . 

In FIG. 2, client systems 104 may be configured as desktop computing 
systems, wireless computing clients, etc. to access servers 102. Such access 
may be made possible via applications and technology such as dbOvernet 
TCP/IP Socket Connection Middleware. Furthermore, servers 102 execute 
common SEServer applications and routines utilizing dbOvernet middleware 
technology. 

Within the processing space of servers 102, a database server system 
such as Microsoft's SQLServer V.7.03 (a DBMS engine) may be instantiated. 
Such a database management system may control data store 106 and may be 
configured in accordance with the present invention to maintain all fuel deal 
data in accordance with the present invention. 

The following discussion further defines an exemplary arrangement for a 
client-server system implemented in accordance with the present invention: 

SERVERS 

MS Windows NT 4.0 (SP6) may be chosen as a Network Operating 
System. 

The DBMS may be Microsoft's SQL-Server (V7.0x) - Service Pack 3. All 
data generated and processed within the context of the present invention is 
stored in MS SQL-Server database tables. Such data is accessed via direct 
SQL statements (embedded in Windows applications, stored procedures, 
forms, and reports). There are several database views that have been setup to 
access aggregated information (for performance and consistency). In addition, 
all of the critical calculations and time consuming procedures such as pricing 
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calculations, routing and rollover processes, etc. are written as Transact-SQL 
stored procedures and are contained on the attached compact disc and are 
discussed in further detail below in the embedded description-tables found 
herein. 

The SEServer may be a Middleware Server Application. The system 
database is accessed via middleware software that uses TCP/IP 
(SEServer/dbOvernet). All databases queried through the system come 
through this middleware component. 

SECrystal (Crystal Reporting Engine Server Application) may be used for 
server side reporting functions, etc. All reports for the system utilizes a remote 
Crystal Reporting engine (SECrystal) server. These reports are run and saved 
on the server for electronic distribution. Crystal Report (V8.0) from Seagate 
Software is used for this function. 

The SEFax (Fax Server Application) may be used for Fax distribution. 
This server application is responsible for sending out reports via a fax device. 
This software monitors a specific directory and when a fax file 'shows up' in the 
directory it will be faxed. 

The MAPI Mail Client Software provides Email (like Microsoft Outlook or 
Outlook Express). The MAPI compliant email service needs to be running on 
the same machine as the report engine server (SECrystal). This provides the 
ability to email reports (Correspondence) automatically. Options should be set 
on this client to automatically check (send/receive) at periodic intervals. 

The Adobe Acrobat Reader (Free PDF Viewer) is used to view reports, 
etc. The server machine that runs the SECrystal reporting server application 
needs to also have the PDF viewer installed. This is used in order to 'spool' to 
paper the print jobs. 

WEB ACCESS - NETWORK CONNECTIVITY 

All functions within the System are available over the Internet (with 
appropriate security). An individual wishing to log in to the system over the 
Internet will need to have appropriate application security to log in, the current 
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application executable program (as contained on the attached compact disc) 
and an ISP account. System administrators will need to furnish access site 
addresses (e.g., IP addresses, domain names, etc.) to users to address the 
systems provided by the present invention. 

CLIENT SYSTEMS 

Client systems may utilize a Client Operating System such as MS- 
Windows 95/98/Me; MS-Windows NT 4.0/2000. TCP/IP network protocol is 
required. Access to the server TCP/IP address (either LOCAL address or 
REMOTE address is required.) 

The system typically includes a single .EXE file(s) (plus approximately 8 
disk compression and graphics DLL's). The system application require only a 
single executable with a few DLL's to reside on the client machine. No other 
client configuration software is required. Upgrades to the client software are 
automatically done when a user first connects (logs in) through the Internet (on 
application startup). A version number check will be made if necessary and a 
new installation program and script are automatically downloaded. 

The Adobe Acrobat Reader (FREE PDF view) is used as a reporting 
system for files saved in the PDF 1.2 format. The default output for all reports 
on the system is the standard PDF format. This provides for email/electronic 
storage. In order to view reports this software (or other third party viewer with a 
file association to .pdf files) needs to exist on the client machine. 

The MAPI Mail Client Software is used for electronic mail 
communications. A MAPI compliant email service needs to be running on the 
client machine to be able to highlight a report and email it using the client email 
address list. This software is not required to run the but is required to take 
advantage of the system's ability to attach reports automatically within an email 
client. 

All client applications are written using DELPHI (V5+) including Delphi 3 rd 
party tools and procedures. Such applications and stored procedures and 
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identified 3 rd party tools are further described in the description-tables found 
below. 

DATABASES, AND CORRESPONDING 
ENTITY RELATIONSHIPS 

The various database tables that make up the system have been divided 
into nine (9) database subject areas. A subject area within this context is 
simply a logical aggregation of tables that support a particular business or 
system function. All of the database tables physically reside in the same 
database, but are not required to so reside. Only the documentation (as 
described below) has been constructed to illustrate these subject areas. It is 
also important to note that there are linkages (not documented here) between 
the various subject areas. 

These database subject areas and a description include: 

Companies: All company related tables (including company name, 
contact name, addresses functions, etc.). 

Contracts: All contract related tables (including contract provisions, 
notes, default standard reporting, etc.). 

Deals: All deal related tables (includes other costs, deal classes, 
correspondence, etc.). 

Volume Inventory: All volume inventory tables (includes production 
interests, daily monthly, calculated values, etc.). 

Operational: All tables that were created to support the system (software 
application). These tables include fax queue tables, printer definition tables, 
system logs, system messages, reporting tables, etc. 

Pipes/Fields: All pipe/field and meter/well related tables. 

Pricing: All tables within the system that are related to pricing (indices, 
price descriptions, baskets, etc.). 

Routing: All tables within the system that define routes (leg definitions, 
daily leg rates, monthly leg rates, nom and actual volume routing instructions, 
etc.). 
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Security: All security related tables within the system (includes user, 
logins, passwords, business functions, etc.). 

The above-described nine (9) logical database subject areas are next 
broken down into the actual tables that reside on the attached compact disc. 
For purposes of brevity, such database subject areas are broken down in the 
following tables: 



<THIS SPACE LEFT BLANK INTENTIONALLY> 
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Table Descriptions 

Below is an inventory of the various database tables that are utilized by the Energy Management System This 
particular inventory indicates the current number of rows (through January 2001), the database (MS SQL Server) 
and the database subject areas (logical grouping of tables). 



Ref # 


Table Name 


Rows 


Database ; . 


Subject 
Area 


Description/Comments 




Companies 

Subject Area 


- 








1.0 


Address 


1,384 


SQL Server 


Companies 


Contains record entries for each address for ait 
companies and contacts within companies 
rmuitiole address tvoes per company and/or 
contact). 


2.0 


Company 


1,242 


SQL Server 


Companies 


Contains a record entry for each company in 
the database. Information on this table 
includes company name. fax. phone and 
primary address reference identifier. 


3.0 


Contact_Group 


908 


SQL Server 


Companies 


Contains a record entry for each contact group 
relationship. This is the mechanism for 
grouping company contact individuals.. 


4.0 


Contact_GroupNames 


8 


SQL Server 


Companies 


Contains a record entry for each contact group 
name. 


5.0 


ContactFunction 


997 


SQL Server 


Companies 


Contains a record entry showing.the contact to 
function relationships for a given company. 


6.0 


Contacts 


3.347 


SQL Server 


Companies 


Contains a record entry for each individual 
contact in the database. Includes full name, 
phone, fax, email, title, eta 




Contracts 

Subject Area 










10.0 


K 


1,414 


SQL Server 


Contracts 


This table contains a record entry for each 
contract within the system. Bank information 
(ABA), Evergreen indicators, termination date, 
fixed pricing, eta type data attributes are stored 
on these records. Each contract on the system 
has an associated parent 'company' (on the 
Company table). 


11.0 


KNetBack 


334 


SQL Server 


Contracts 


This table contains the netback pricing tiers 
associated with a given contract The parent 
table for this entity is the contract table (K). 
The netback pricing tiers are volume and date 
influenced. 


12.0 


Knotes 


589 


SQL Server 


Contracts 


This table contains an optional record entry for 
each contract on the system. If there are no 
notes associated with a contract then the 
records are not inserted on the database. This 
provides the users with a free form area for 
keeping notes about a contract 


13.0 


Kproducts 


1.049 


SQL Server 




This table contains a reference to the products 
that are available (oil. gas. Bquids. eta) for a 
given contract A product has to be associated 
to a contract before a deal can be setup using 
that contract for that product 


14.0 


KreportOefautts 


48 


SQL Server 




This table contains the entire standard 
reporting defaults for a particular entity. These 
reports include invoices, remittance, vouch rs, 
deal confirmations, eta 


15.0 


KreportOvemdes 


O 


SQL Server 




If a particular contract has its own unique 
standard reports then a reference to these 
unique reports is stored in this table for the 
contract in question. 
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Table Name 

Kservices 



This table contains a reference to the services 
that are available (marketing, end user, pass 
thru, eta) for a given contract A service has to 
be associated to a contract before a deal can 
be setup using th at contract for that service. 



20.0 RdeatClass 



21.0 



22.0 



25.0 



26.0 



27.0 



RdealClassA 



RdealClassRuies 

Engine Jviaster 
Engme_Masterfrice 



Package 



PackageCosts 



PackageCorrespondence 



28.0 PriceComponents 



29.0 



PriceDesc 



Volume Inventory 
Subject Area 



23 



448 



SQL Server 



SQL Server 



SQL Server 



65,351 



SQL Server 1 Deals 



Deals 



This table is a reference table that indicates the 
types of deal class options that are available. 
The context of each class is 0-Purchases 
1=Sales and 2=Both. The description field 
indicates the possible answers (but the 
rOealCIassA table contains the actual answers 
that can be a 



This table is a reference table that indicates the 
possible deal classification options for each of 
the classifications defined in the rDealClass 
table. 



This table contains record entries for every 
combination of deal classification answers 
(rOealCIassA table). Each of these 
classification options can have its own set of 

calculation rules/etc associated withJL 

this table contains a record entry for eacn price 
entry effective date (heade r record] 
This particular table contains the individual 
pricing components associated to a given deal 
on a given effective date (parent record is on 
the Engine Master table). When the user of 
the Energy Management System enters a 
price, this is the table tha t pets updated. 
This table contains a record for each deal that 
has been setup on the system. Start Date, End 
Date, Deal Name, Contract Company, etc. are 

^Marled on this table. , 

This table contains entries for all 'other costs 
associated with a given deal. Each of these 
'other costs* will have unique STlD's (deal or 
meter level) and have calculated 'Engine' 
records automatically generated (when a 
calculation runs) 



this table contains entries for all of the 
electronic correspondence between the parties 
to the deal (deal corifirntations. avaitabitty 
reports, remittance detail, vouchers, etc). 



This table contain record entries 
component that can be set aside tor pricing 
purposes (on a deal). Examples include 
•DAILY INDEX', 'MONTHLY INDEX', 
'GATHERING', etc These tags will be 
associated to each component of the price to 
allow for future queries and reporting. In 
addition, these tags will provide an audit trail of 
all pricing related information. 
This table contains a record for each deal 
description (or comments) within the system. 
These price description records (only 1 per 
deal) provide the users with a place to put free 
form text to help describe the price of the deal. 
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Ref# 


Table Name 


Rows 


Database 


Subject 
Area^ 


DescriptioiVComments^ ^^vv . i-p 


30.0 


Engine 


280,970 


SQL Server 


Volume 
Inventory 


This table contains record entries for each 
calculated transaction that the system attaches 
to volume inventory items. Each transaction 
has a unique a • iu jiransBwiuii iu; uwi «« » 
defined in the Engine JVansacbonUst table. 
Indicators on this table determine the 
disposition of the transaction. 


31.0 


EngineJTransactionList 


36 


SQL Server 


Volume 
Inventory 


This table contains record entries that define all 
of the transactions that can be calculated and 
stored in the Engine table. The ST1D field Is 
the unique transaction identifier. 


32.0 


Gaslnv 


159,501 


SQL Server 


Volume 
Inventory 


This is the primary table were all volumes 
(nominated and actual) are maintained This 
table contains the header record entries that 
shows by month, company, transaction, 
pipe/field & meter/well the nominated volume 
and the estimated actual volumes. References 
to price types, contracts, etc. are stored on 
each record. 


33.0 


GaslnvO 


4,145,617 


SQL Server 


Volume 
Inventory 


This table contains the detail (DAILY) 
nominated and estimated actual volumes for 
the Gaslnv table. 


34.0 


Prod Interest 


7,999 


SQL Server 


Volume 
Inventory 


This table contains a record that lists the 
production interests that are held for a given 
meter/well and contract (with date 
effectiveness). 


35.0 


ProdPkg 


4,080 


SQLServer 


Volume 
Inventory 


This table contains a record that indicates (by 
month) the contract and the deal ID of a deal 
that was generated automatically within the 
•Avaaabiliry' (equity purchase deal creation) 
area of the system. 


36.0 


ProdSum 


39.296 


SQL Server 


Volume 
Inventory 


This table contains records that indicate (by 
month and meter/well) the gross mmbtu's and 
the Btu factors. 


37.0 


ProdVol 


44,187 


SQL Server 


Volume 
Inventory 


This table contains record entries (by month 
and meter/well) which show the receipt and 
delivery mmbtu's per day. 



40 



Operational 
Subject Area: 

ApplicationMessages 



55,882 



SQL Server 



Operational 



This table contains a 'rolling' 7 day listing of all 
application messages (such as those that are 
displayed to the console during a calculation). 
" ~ ~ record entries to hold ail of 



41.0 



42.0 



43.0 



ExceptionCategories 



SQL Server 



Operational 



ExceptionUst 



2.171 



SQL Server 



Operational 



This table contains i 
the exception 'reasons' that will be used 
whenever an exception even occurs. There 
can be multiple types of exception categories. 
This table contains entries for the actual 



exception events that get logged by the system. 
These represent an audit trail of non-normal r 
error type information. This table is linked to 
the ExceptionCategories table because each 
exception event (in this table) requires a reason 
category. 



LogTable 



SQL Server 



Operational 



This table is used for debugging purposes only 
a nd is not used in any screens or reports. 

record for each available 



44.0 



PrinterDef 



SQL Server 



Operational 



This table contains a i 
printer (including driver and port). 
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Ref # 


Table Name- 


Rows -^aase 

I 


Subject 
-Area 


:Descjiption/Co(iuneiils. > y :v ^ 


45.0 


RgasMonth 


1,440 


SQL Server 


Operational 


This is a reference table that contains a record 
for each month from 1/1980 thru 12/2099. In 
addition, this table also contains the status and 
status update sequence number for the 
particular month. This status is used in order to 
enable/disable certain functions within the 
Energy Management System throughout the 
month. 


46.0 


RGasMonthStatus 


1,873 


SQL Server 


Operational 


This represents a historical audit table that will 
be updated every time the monthly status for a 
given production rnorttn ts moorned (via triggers 
on the RgasMonth table). This provides a 
mechanism of identifying who & when the 
changes were for the status, over time. 
All system messages are stored in this table. 


47.0 
46.0 


SEMessages 

SEAudrt 


1,251 


SQL Server 
out server 


Operational 
Operational 


This table contains record entries for those 
events that are deemed 'audrtabte*. Some . 
examples include 'Login' events, Actualization 
balancing events, standard report submission 
events, etc. 


49.0 


SEImages 


•5 
4. 


oul oerver 


Operational 


This table contains record entries that contain 
graphic images for the screen and reports used 
throughout the system. 


50.0 


SELocations 


3 


bUL oerver 


Operational 


This table contains record entries that define 
the server paths (network folder locations) 
where certain key correspondence items are 
found. For example (report location, deal 
correspondence, etc). 


51.0 


SEProcessingCodeTypes 


15 


SQL Server 


Operational 


This table contains the Type* codes to the 
reference table 'SEProcessingCodes 1 . An 
example is the type code of 'CONTRCTPRD* 
which describes a reference code for contract 
products. 


52.0 


SEProcessingCodes 




OUL. OCIVCl 


Operational 


This table contains reference codes for venous 
fields used throughout the Energy Management 

System. 


53.0 


SERptsExecutedStats 


19,117 


SQL Server 


Operational 


This table contains record entries that lists the 
start and end date and times for ail reports that 
were submitted. This provides 'Statistics on 
how long to execute/etc. 


54.0 


SERptsGroupltems 


218 


SQL Server 


Operational 


This table contains entries of each specinc 
report that exists within a reporting tab (group) 
within a specinc reporting folder (category). 


55.0 


SERptsGroups 


36 


SQL Server 


Operational 


This table contains a list of all available 
reporting tabs (groups) within each reporting 
folder (category). 


56.0 


SERptsltemDetail 


123 


SQL Server 


Operational 


This table contains the list of all available 
reports within the system. 


57.0 


SERptsltemParms 


657 


SQL Server 


Operational 


This table contains record entries for each 
report parameter for each report defined to the 
system. Options exist for substituting a 
different label name than actual parameter field 
name. 


58.0 


SERptsQueue 


5,667 


SQL Server 


Operational 


'submitted' reports (report queue). When 
reports are automatically removed from the 
system the record is removed from this queue. 


59.0 


SERptsQueueOistribute 


7,855 


SQL Server 


Operational 


This table contains entries that dictate how to 
distribute the output of reports from the queue 
(fax. email, printer, etc.). 


60.0 


SERptsQueueNotify 


276 


* SQL Server 


Operational 


This table contains entries that indicate who 
(and if) individuals or groups have been not* * 
that the report has finished. 


61.0 


SERptsSchedule 


0 


SQL Server 


Operational 


This table contains records that define sp? 
schedules for the running of scheduled ^ 
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Ref#- 


Table-Name^; /[^x^z 


...Rows 


. Database 


Subject; -I 
Area* 


j)escription/CcTnments V*P : ^ ; ^ "■*.,•■■■ 




62.0 


SERptsScheduledReports 


0 


SQL Server 


Operational 


This table contains record entries that define 
which reports to run as part-of specific 
schedules. 




63.0 


SERptsScheduledGroups 


u 


oUL oerver 




This table contains 'groups' for scheduling. 
This provides the ability to assign multiple 
individuals to a specific group and have the 
group belong to the schedule. 




64.0 


SERptsScheduledUserGroup 
s 


0 


SQL Server 


Operational 


This is the actual table that contains the 
members within a schedule group. Each entry 
in this table defines the group. 




65.0 


SERptsTablesUsed 


896 


SQL Server 


Operational 


This table contains documentation on what 
tables, views or stored procedures are used 
within each report 






Pipes & Fields 












80.0 


Meter 


4,335 


SQL Server 


Pipes and 
Fields 


This table contains a record entry for each 
well/meter that has been setup on the system. 
The pipe/field, name, county and state are 
stored here. 




81.0 


MeterNotes 


935 


SQL Server 


Pipes and 
Fields 


This table contains a record for notes pertaining 
to meters/wells. 




82.0 


PipeField 


372 


SQL Server 


Pipes and 
Fields 


pip/field defined on the system. The company 
and the pipe/field description are stored here. 


If] 
o 


83.0 


MeterRates 


3,980 


SQL Server 


Pipes and 
Fields 


This table contains the entire pressure base, 
Btu factors by effective date for specific 
meters/wells. 




84.0 


MeterAllocations 


551 


SQL Server 


Pipes and 
Fields 


This table contains entries for the allocation 
information on the meter/well. This includes 
accounting cross-reference codes (id and 
deck). 


n i 




Pricing; 
Subject Area 












90.0 


GCIndex 


142.268 


SQL Server 


Pricing 


This table contains record entries by Day for 
daily index prices AND/OR a single entry for 
monthly index prices (1" day of month for 
monthly indices). 




91.0 


IndexRef 


228 


SQL Server 


Pricing 


This represents the master table of all defined 
price indices within the Energy Management 
System. One record entry per index exists 
within this table. 




. 92.0 


IndexBaskets 


14 


SQL Server 


Pricing 


This table contains a record entry for each 
index basket established on the system These 
index baskets can be associated to sales or 
purchase deals just as normal indexes are 
associated to them. Simple averages are 
calculated with all index items within an index 
basket 




93.0 


IndexBasketLink 


36 


SQL Server 


Pricing 


This table contains the actual indices that are 
currently associated with an index basket An 
unlimited number of indices can exist In a 
basket A simple average of all the prices 
within the basket is used. 






Subject Area 


; ;-;-> : ;!-V; 










101.0 


LegRef 


4,226 


SQL Server 


Routing 


This table contains record for each unique 
transportation leg (meter-to-meter) on the 
Energy Management System. 
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Ref# 



102.0 



Table Name- 



Leg 



Rows 



57,830 



Database 



SQL Server 



Subject: 
Area 

Routing 



Description/Comments 



This table contains a record for each active leg 
within a given month. Nomination and actual 
rates that the leg utilizes during the month are 
posted on each record. These rates are used 
with the actual routing instructions (LegDetail 
table). 



103.0 



LegO 



SQL Server 



Routing 



This table contains OPTIONAL entries for any 
dairy leg rates that need to be utilized within a 
given month. Dairy rates are checked.PRIOR 
to the monthly rates (on the Leg table) when 
setting up the actual routing instructions 
(LegDetail table). 



104.0 



LegDetail 



1,716,695 



SQL Server 



Routing 



This table contains the detail routing 
instructions for all volumes purchased all the 
way through the sales points for that particular 
volume. Nomination AND actual routing 
instructions are stored for each meter/well that 
had volume activity during the month. All 
volumes sold can be tracked back to originating 
purchase points. 



105.0 



WASPResovedRouting 



34,304 



SQL Server 



Routing 



hj 
U 

s 



This table contains record entries that show th 
pool level calculated totals for all receipt and 
delivery points within the system. 'Common', 
'Dedicated' and 'None* pools are aggregated 
and the total numbers stored here. Only 
'Common' pool volumes and dollars represent 
the totals from more than one purchase point 
(shows weighted average pricing based on 
volumes purchased and/or transported). 



110.0 



111.0 



112.0 



Security 
Subject Area 



GCUser 



GCButton 



GCSecurity 



27 



58 



1.548 



SQL Server 



SQL Server 



SQL Server 



Security 



Security 



Security 



This table contains a single record entry per 
unique user (employee) on the system. The 
character based (up to 12 character) login ID 
AND an internal user id (integer) are unique 
to this table, 



keys t 

This table contains records that represent the 
system functions that have specific security 
rules associated with them on the system. For 
example a system function of 'DEALS' has 
been setup in order to define security 
relationships between users (GCUser table) 

and this function. 

This table stores the relationships between 
users on the system (GCUser table) and the 
system function that they have access too 
(GCButton table). A specific access privile 
stored for each of these relationships (19" 
READ ONLY, READ/UPDATE, 
READ/UPDATE/DELETE or SUPER) 
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Referring now to FIGS. 3A-3N, depicted therein are entity relationship 
diagrams that illustrate data relationships among tables and corresponding 
table entries used to implement the systems and methods that carry out the 
business process illustrated in FIG. 1. The database tables used logically 
categorized above into the above-identified nine (9) subject areas are 
maintained within data store 106 (FIG. 1) t and are included among the files 
present on the attached compact disc, and are further defined in detail in FIGS. 
3A-3N. Those skilled in the art will readily understand the data relationships 
among relational database tables as shown in FIGS. 3A-3N. Accordingly, for 
purposes of brevity, further comments about FIGS. 3A-3N have been omitted. 

In addition to the tables described and specified in the tables listed 
above, the following table illustrates an inventory of the various database views 
that utilized by the systems and methods provided by the present invention. 



<THIS SPACE LEFT BLANK INTENTIONALLY> 
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View Descriptions 
Below is an inventory 



of the various database views that are utilized by the Energy Management System: 




Ref# 

7.0 



View Name 
Vcontact_Production 



■' Description/Comme nts _ _ : 

Display the production contact for a given company. This is the comae useo b*Availabilrty 
estimates/etc 



8.0 



9.0 



Vcontact_volconfirm 



Display the contact responsible for confirming volumes within a given company, 
contact used for volume confirmations in the 'Availability' phase. 



VcontactFunction 



Oiplay a list of all contacts for a given company along with their respective functions (accounting, 
volume confirmations, eta) - — 



10.0 
11.0 



VContacts 
VETID Dates 



Displ ay name and addresses for contacts. ; . — __ — 

Display the engine start effective and end dates for a given engine transaction id (based on 
package). This view is used VERY LITTLE because of p erformance issues. 



16.0 



VgaslnvDjslomChg 



Display list of daily volumes where the nomination volumes are different 
days. ^ 



17.0 
18.0 



19.0 



27.0 



VKTermination 
VtegOetaiLlvleterTotals 



VlegDetail.PipelineComparis 



Display routing information summarized by meter. — 

Display routing information in a format that is used for the pipe/field comparison report Used i 




VPackage, 



Info 



VPrevGasMonthStuff 



Display detail list of information concerning a package (includes contacts, names, 
Displays current month v olume totals versus previou s month volume totals. 

— t — : — — i . Mmriiiftinn vrnln 



28.0 

29.0 



30.0 



VprodConfirmLetters 



Display contact information for use with correspondence on production 
in the confirmation process in the 'Availability production month phase. 



Vprodlnterest 



Display a list ofcorrtracts and meters to confirm the production interests. This is used primarily in 
the 'Availability* production month phase. 



31.0 



VRequestProduction 



DteplaV'iist'of prodVction'interest volume and meter infomwtion. "^P™^ **? tirwm 

■Availability production month phase and is used when sending out estimate reports to producers. 
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Once all software and data as described above has been properly 
installed on one or more server systems 102 and within one or more coupled 
(networked) client systems 104 as illustrated in FIG. 1, use and operation of the 
systems and methods provided by the present invention may be commenced. 
Such operations may be in relation to the general use application (Energy 
Management System - EMS) or the limited use/user/function application 
(Producer Control Console - PCC) provided on the attached compact disc. In 
either case, the present invention facilitates a client-server application 
environment that includes, among other things, a user interface that is pleasing 
to users and which permits easy and ready access to system functions and 
operations. Such a user interface may be a graphical user interface or GUI that 
is configured to permit a user to engage in window-operations to bring about 
database operations that affect fuel deal data and the like in accordance with 
the present invention. Such a GUI is illustrated by way of screen shots (images 
of computer monitor screens) that are used to permit generation of, 
manipulation of, reporting of , and all other system operations relating to fuel 
deals and corresponding fuel deal data. 

For example, reference is now made to FIGS. 4A-4Q which illustrate a 
data processing application running within a client system to facilitate at least 
some of the operations carried out to effect the business process illustrated in 
FIG. 1. FIG. 1, for example, represents an opening main menu screen through 
which a user may select "PERSONAL" operations related to setting up a 
personal profile to affect user-preferred presentation of data (e.g., name, screen 
colors, etc.). Additionally, a user may select "PRICE-INDEX" to affect fuel 
pricing and index related data. A user may select "COMPANY" to control lists 
of producers, and other related company entities. A user may select other 
options corresponding to the steps involved and described with regard to the 
MONTH OF FLOW PROCESS illustrated and described with reference to FIG. 
1. 

The other screen shots shown in FIGS. 4B-4Q further illustrate specific 
features of the GUI that has been designed to facilitate the implementation of 
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the systems and methods provided by the present invention. For the purpose 
brevity, further detailed comments related to such screen shots has been 
omitted. 

SYSTEM IMPLEMENTATION AND FUNCTIONALITY 

As noted above, the present invention utilizes stored procedures in the 
form of database management system procedures and functions which are 
executed server-side and client-side to facilitate the present invention's systems 
and methods. Listed in the following tables, is a detailed break-down of all the 
stored procedures, tools, and modules used to facilitate such systems and 
methods. The actual source code and instructions contained with in such 
procedures, functions, and modules is contained on the attached compact disc. 

STORED PROCEDURES 

Below is an inventory of the various database-stored procedures 
(procedures and functions) that are utilized by the systems and methods 
provided by the present invention. Each of the stored procedures and functions 
are written in the Transact-SQL dialect. All of the stored procedures are 
prefixed with "uspj' which stands for "User Stored Procedure." This provides 
an ability to differentiate those procedures bundled with the DBMS versus those 
created for the systems and methods provided by the present invention: 
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Stored Procedures 



Below is an inventory of the various database-stored procedures (procedures and functions) that are utilized by 
the Energy Management System. Each of these stored procedures and functions are written in the Transact-SQL 
dialect All of the stored procedures are prefixed with u usp_" which stands for "User Stored Procedure". This 

p provides an ability to differentiate those bundled with the DBMS versus those specifically created for the EMS 

yg application. 



Ref# 

1.0 


Stored Procedure Name 
Usp_DailyCleanup 


Description/Comments . --- . v.-/, • . 

This procedure is run everyday and is responsible for any cleanup activities (like 
rolling aqed messages off the ApplicationMessages table). 


2.0 


UspJGetCalcindex 


Retrieves the weighted average price for a given volume item. This routine is 
invoked during the WASP calculation in order to obtain the price for the 
meter/well and post it to the Engine database table. 


3.0 


Usp_fGeUndex 


Retrieves the daily or monthly price index for a given day. Used during the 
pricing calculation routine. 


4.0 


Usp.fGetlndexBasket 


Retrieves and calculates the index amounts for the price lines whenever an 
index basket price variable has been entered. This particular function will return 
the average price (simple average) of all indices within the basket for a given 
month/day. 


5.0 


Usp_fGetNetbackPercentage 


This function will return the actual netback percentage to be used for a given 
production month and contract When it calculates the netback it looks at 
volumes and tier instructions that have been setup on the contract The number 
it returns is the netback percentage to utilize. In addition, this routine brings 
back the specific percentage to use for the product being calculated (gas, 
liquids, oil, etc). 
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Ref# 

o.u 


Stored Procedure Name 

Usp fGetProdlnterestID 


Description/Comments 

This routine brings back the production interest information fore particular 
ownership interest. . Z . - 


t n 


t len ff?ptProdPkn 


This procedure brings back the 'deal id' (if one already exists) when posting 
volumes through the 'Availability' screens. If a deal does not already exist (in the 
current production month) then a new deal is created and that ID is sent back. 


8.0 


Usp_fGetWASPIndicator 


This function accepts a deal id (package ID) as it's input. It then reads the 
DealClass table and the rDealClass table(s) to determine if this particular deal 

_ , . i ia/a cDiHia ha^pH on it* Ha edification scheme The return 

Should be Considered W/\or3Dlc oa&evi un iu> uctaauiuiuuii awiciuc. i no 

values are either 'None'. 'Common' or 'Dedicated'. 


9.0 


Usp_fGetWaspType 


This procedure will send back the WASP type field (GAS, OIL or UQUIDS) when 
passed a specific product ID. This procedure is used during the calculation in 
order to determine which set of netback rules off a contract to use. 






This procedure accepts a date and sends back the last date in a production 
month. 


11.0 


UspJLastDay 


This procedure accepts a date and sends back the last date in a production 
month. 


12.0 


Usp_fPipeContactlnfo 


This procedure, when passed a pipe/field id, will send back the specific contact 

information requested (like accounting contact, volume contact etc.). 

This function will return the production month to use for a given production day. 


13.0 
14.0 


Usp GasDayToGasMonth 
Usp_GetProductVolumeRound 


This routine will return the rounding precision necessary when calculating 
volume information for specify products (Oil calculates to 2 decimal places. Gas 
to zero etc.; 


15.0 


UspJJnePrice 


This is the actual procedure that will calculate the Engine records for a given 
deal (volume related STID 8 or 9 type records). 


16.0 


Usp_message 


This routine handles all of the progress' messages that are issued during the 
calculation, rollover, actualization, and etc. type events on the system. This 
routine will optionally post this information to the ApplicationMessages table for 

historical reference (audit). ; 

This is the main driver routine for Step 2 of 4 of the actualization process. 


17.0 
18.0 


UspjActual!ze_BaiPurchases 

Usp_j>Actualize_baiFurcnasesoneciv 


Thk mutinti will check to see if all of the meters/wells on a given pipe/field have 

| fll9 fUUIJIIw Will UlCvn IW www * ' w« *• ■ — -» — W w • 

been actualized. If not then it sends back a bad return code. All meters/wells 
are required to be 'checked' (actualized) prior to balancing of purchase routing 
points 


19.0 


Usp_pActualize_Ba!PurchasesCtear 


This routine is the actual routine that will adjust all purchase meter imbalances. 
These imbalances are adjusted forward THROUGH the sates point based on 
nomination routing instructions (used as a map). 
This is the main driver routine for Step 3 of 4 of the actualization process. 


20.0 
21.0 


Usp_pActualize_Ba (Sales 

Usp_pActualize_BalSalesCheck 


This routine will check to see if all of the purchase meters/wells routing balances 
(from step 2 of 4) are balanced. If any meter/well on the pipe/field is out of 
balance then this routine sends back a bad return code. All meters/wells on the 
pipe/field are required to be 'balanced' prior to balancing of the sales points. 


22.0 


Usp_pACtua lize — D a *o a ie» w tea i 


This procedure is the final procedure invoked by the usp _pActualize_BalSaies 
main driver procedure. It is responsible for posting imbalance amounts to the 
internal clearing purchase or sales deals. 


23.0 


Usp_pActualize_BalSalesOver 


This procedure attempts to reconcile any outstanding balances that result in 
OVER supplying of volume to a particular sale: Nomination information is used 
by this routine as a 'road map' on how to allocate this volume. 


24.0 


Usp_pActualize_BalSalesUnder 


This procedure attempts to reconcile any outstanding balances that result in 
UNDER supplying of volume to a particular sale. Nomination information is used 
by this routine as a roao map on now w duuLdie ui» »wumo. 


25.0 


Usp_pFilllndex 


This procedure will initialize the records within the 'GCindex' table with dairy 
entries (for daily indices) and monthly entries (for monthly indices). The monthly 
record entries are only on the first day of the month. 


26.0 


Usp_pFilllndexSingle 


This procedure will populate ine ooinaex iaom wiin a pin** uiuba onuy iw a 
SINGLE index. 


27.0 


Usp_pGaslnvD_Fill 


This routine initially populates the daily volumes on the GaslnvD table. These 
are initially populated with zeros (anytime a meter/well is added to a deal). 


28.0 


Usp_pGaslnvDJMomEOM 


This routine is used in the 'Availability' area of the EMS system and is used to 
take a given volume amount and propagate that volume amount to all days in 

the month. 

This routine is used to post record to the audit table within the system. 


29.0 
30.0 


Usp__LooAuditlnfo s_ 

Usp^pPackageRevision 


This routine is used to increment the revision number field on the deal. Certain 
types of changes to a deal will automatically increment the revision number on a 
deal and this update is done through this routine. 
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Rein 


Stored Procedure Name 


Description/Comments :-v:>' T ^v::^ 


31.0 


UspjjPostCIassificationRules 


This procedure is executed (usually by triggers on the rDealQass and 
rOealClassA tables). It can be executed stand-alone. This procedure will 
ensure that a record is created in the rOealClassRules table for every 
combination of deal classification codes (dcA values on the rOealClassA table). 


32.0 


Usp_ProdPush 


This routine is used in the 'Availability' phase of EMS and is used to initially 
populate a particular month with ownership interest information, by meter/well. 


33.0 


Usp_pPushMeter 


.This. routine is used in the 'Availability' phase of EMS and is used to populate a 
single meter/well ownership interest to its respective deal (package) and volume 
inventory item (Gaslnv/GaslnvD). 


34.0 


Usp _pRouteBuildLegHistory 


This routine creates the 'Leg* records for a given meter/well. When a new route' 
(Leo Reft is defined on the svstem then this routine will aet invoked to in Math/ 
seed the 'Leg' table with entries in order to allow routing. 


35.0 


Usp_pRouteBuildLegHistoryAII 


This routine oets invoked when a orodudion month is initially nnpnoH *a th» 
'Sales' phase. All ACTIVE meters and tegs will have their respective 'Leg' table 
records populated for that production month by this routine 


36.0 


Usp_oRouteCopyLegHistoryActuals 


This routine gets invoked when the status of a production month changes from 
'Sales' to 'Invoiced' All nomination routine instructions /in the *l «on»*aH* table) 
are then copied by this routine. This provides the mechanism to have actuals 
different than noms while preserving the nom instructions. 


37.0 


Usp _pRoutePostChange 


This procedure gets invoked whenever a change to a specific route is requested 
(i.e. modifications of volumes between hops). 


38.0 


Usp_pRoutePostDeallnfo 


I hie nrocpHiiro note invnkaH tn 'caoH' tha '1 anrWail' tnKU un+K mi 

■ ii» y>\ ulcuuic ycia invoi\CQ lu scvu uie usgmnau uoib wiul rouung 

information. This is invoked when new meters/wells are added to deals. 


39.0 


Usp_pRoutePostDeallnfoVols 


■ ii» k< uteaure gets invoivea 10 populate me specmc volumes on each of tne 
'Leg Detail' entries (daily) for deal inventory items. 


40.0 


Usp_pRoutePostDelete 


Thus nmroriim nate irtvmlms^ uihanauor a WalAtinn ia rm atait mm mm wmmm*. 

i ma piuccaurc gets invoKeo wnenever a aeteuon is request eo on tne routing 
(LegOetail) information. 


41.0 


Usp_pRoutePostLeg Rates 


i hk» pruwjure gets invoKeo in oruer io posi me raxes (ruei, pvr, transport, 
gathering, etc) to each of the 'LegOetail' records in the database. Daily rates 

(LeoD table) overrides monthly rates /Lea tartlet and this nmnwli in» a»n«itnB« that 

tauic/ uvuniuca lliwliuilj l OIC3 \L»C^J loUKI/ OIIU U1I9 pi UWCQUiO CnSUlcS IftBl 

priority. If a rate gets changed for a leg this routine gets invoked to update all 
existing routes (LegOetail) records. 


42.0 


Usp_pRoutePostSale 


TniS DFOCedure Gets invoked in order to nnst volume (rruttm it\ it\ a «al«M it Am tin 

the LegDetail table). 


43.0 


Usp j?RoutePostTransport 


This orocedure asts invoked in order to oost volume fraute W\ to a tramtnnrtati*>n 
point (in the LegDetail table). 


44.0 


Usp_pRouteRemoveLegDetails 


This routine will remove anv/all 'LeoDetaN* t routina instrudions) when a 
meter/well for a specific deal is removed. 


45.0 


Usp _pSERPT_GetAdditionalReportlnfo 


This routine is used by all of the 'standard' reporting procedures to obtain 
specific report fields needed when running a standard report 


46.0 


Usp .j>SERPT_PostReportToCorrespondence 


This routine will post a 'PackageCorrespondence* table record to a particular 
deal that is affected by the 'standard* report being run. This routine is called by 
all standard report routines. 


47.0 


Usp _pSERPT.PostReportToDistribution 


This routine will post a report distribution request to the SERptsQueueDistribute 
table. This is either a request to 'PRINTER*, 'EMAIL' or 'FAX*. 


48.0 


Usp _pSERPT_PostReportToQueue 


This routine is used by ail of the standard report routines and will post an actuaJ 
report request (queue item) to the SERptsQueue table. 


49.0 


Usp_pSERPT_RunReportAvailConfirms 


This routine is responsible for running the 'Availability 4 confirm reports. 


50.0 


Usp_pSERPT_RunReportAvailEstimates 


This routine is responsible for running the 'Availability 1 estimate reports. 


51.0 


Usp j)SERPT_RunReportOealConfirm 


This routine is responsible for running the deal confirmation reports (from the 
deal detail screen on EMS). 


52.0 


Usp_pSERPT_RunReportlnvoice 


This routine is responsible for running all standard invoice reports. 


53.0 


Usp_pSERPT_RunReportRemittance 


This routine is responsible for running all standard remittance reports. 


54.0 


Usp_pSERPT_RunReportVoucher 


This routine is responsible for running all standard voucher reports. 


55.0 


Usp_pSERPT_SetAParameterBoolean 


This routine is used by the standard reporting routines and converts Boolean 
parameters for posting on the report queue (SERptsQueue) table. 


56.0 


Usp j)SERPT_SetAParameterDate ' 


This routine is used by the standard reporting routines and converts date and 
date/time parameters for posting on the report queue (SERptsQueue) table. 


57.0 


Usp_pSERPT_SetAParameterDecimal 


This routine is used by the standard reporting routines and converts decimal 
(number) parameters for posting on the report queue (SERptsQueue) table. 


58.0 


Usp_pSERPT_SetAParameterlnteger 


This routine is used by the standard reporting routines and converts integer 
number parameters for posting on the report queue (SERptsQueue) table. 


59.0 


Usp_pSERPT_SetAParameterString 


This routine is used by the standard reporting routines and converts string 
parameters for posting on the report queue (SERptsQueue) table. 
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Stored Procedure Namey 



Description/Comments; — — 

This routine is used by the standard reporting routines and is-responsible for 
determining WHICH report to use. The default reports are in KreportDefaults 
table. However, any given contract can override the default (KreportOverndes 
table). 



Ref#^ 
60.0 



UspjSERPTJ/vhichReport 



61.0 



Usp_PSPrice 



This is the main pricing routine for the volume inventory items (regular 
purchases and sales) 



62.0 



Usp.PSPriceAII 



This is the main procedure for calculating the prices for a given month on a set 
of deals (volume inventory pricing, ST1D 8 & 9). Parameters to this stored 
procedure dictate the type of price to calculation (Norn or Pipe/Field Actual and 
Sales versus Purchase, etc). 



63.0 



Usp_PSPriceAnyNewlnvoicesNeeded 



This routine is responsible for assigning new invoice and remittance numbers to 
the volume inventory table (Gaslnv). If new meters/wells (volume entries) get 
entered during the actualization process then this routine will ensure they are 
assigned unique numbers. 



64.0 



Usp_PSPriceAssignlnvoiceNo 



This routine assigns invoice numbers to all sales 
month is promoted to the 'Invoiced' phase 



65.0 



Usp_P£PriceAuto 



This procedure run everyday and checks tor any production month either in the 
•Sales' or the Invoiced' phase. If any production months are within these 
phases then this procedure will invoke the calculation routine 
(uspjsPriceAutoMonth) for them. 



66.0 



67.0 



Usp_PSPriceAutoMonth 



This is the main driver routine for the calculation of an entire month. 



Usp.PSPriceComponentsCheck 



l Ilia la »IC mom murci i uum .w. 

This procedure will automatically insert system generated price components (like 
WASP or Netback Percentage) to the Engine^Master table. It is invoked by the 
usp PSPricel procedure when calculating prices on a deal for a given month. 



68.0 



Usp.PSPriceCost 



This is the routine that calculates the 'Other Cost entries and posts calculated 
results in the Engine table 



69.0 



Usp.PSPriceCostAII 



This is the main driver routine for looping through all of the 'Other Costs' in a 
given mon th and invoking the usp_PSF riceCost routine for each one. 



70.0 



Usp.PSPriceCreateActualEntries 



This procedure copies the pricing entries setup on 
(Engine_MasterPrice) from nom to actuals 



71.0 



Usp.PSPriceMarkActualAdjustments 



This procedure gets invoked by the calculation routine to mark any volume 
inventory item (Gaslnv) whenever a difference is detected between nominations 
and actuals. 



72.0 



Usp.PSPricePopulateEngine 



This procedure will populate the Engine table FROM the Engine.Master table 
For daily index price entries this procedure will automatically propagate the daily 
index price to all days of the month where there is a volume (at least until anew 
pricing entry is found ). Only volume entrie s are populated here (ST1D 8 & 9). 



73.0 



Usp.PSPriceTransportAII 



This routine' calculates all of the transport costs tor a given production month. 
These transport costs (and volumes) are posted In the Gaslnv (pncetype=3) 
table and deals are posted (if needed). These deals are tagged with the specific 
transport contract 



74.0 



75.0 



76.0 



77.0 



78.0 
79.0 



Usp.PSPriceWASPCalc 



Usp PSPriceWASPCalcResolveDriver 



Determines and resolves all wasp 'Common' and 'Dedicated' pools. Dedicated 
pools are sanctioned sales. This is the main driver procedure for the wasp 
portion of the calculation. Third party (pool » -None') are also processed within 
this procedure but not for the intent of obtaining a price for them, totals used 
primarily for profit margin reporting. 



This is the main driver component for drivi ng the WASP calculation. 



Usp_PSPriceWASPCalcResolveN 



1 1 IIO 19 U ic mam vjiiwwi wki ■ . ^ — 

Traces back sales totals from all sales meters back to their originating purchase 
points. The table updated here is the WASPResolvedRouting table. The 
'LegDetair table is used extensively in this calculation. This ts a highly 
ITERATIVE process. 



Usp.PSPriceWASPCalcResolveSalesN 

Usp ,, PSPriceWASPCalcSaiesN 
UsplPSPriceWASPCIearMontn 



This procedure creates the entries in the WASPResolvedRouting table and 
posts original sates volumes and amounts. This is done just pnor to the routine 

that resolv es these sales totals back to the p urchase points. 

Sums all WASPable sales by sales meter into the WASPSalesMeterTotals table. 
This routine runs when a production month is promoted to 'Completed' phase. 
Any volume inventory items (Gaslnv and/or GaslnvD) or routing items 
(LegDetail) that contain zeros are removed so that only relevant information is 
stored in the database for historical purposes. 



80.0 



Usp_PSPriceWaspDivieOutProceedsN 



This procedure is the main procedure that will distribute the proceeds from those 
deals that have been designated to have their respective proceeds distributed 
via the Financial Overrides' setup on the deal 



81.0 



Usp_ProdVolSet 



This routine is used in the 'Availability pnase to setup the ownership interest n 
a particular pipe/field and meter. ProdSum and ProdVol tables for the current 
production month are popu lated with this procedure. ; 
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Stored Procedure Name 


Description/Comments ,> _ 


82.0 


Usp_ProdVolSetAII 


This routine is used in the 'Availability' phase to setup the ownership interest on 
all pipe/fields and meters. This routine invokes the usp_ProdVolSet routine for 
each meter/well in the loop. 


83.0 


Usp_PS Rollover 


This routine gets invoked when a production month goes from 'Availability' to 
'Sales' and is responsible for copying deal information month-to-month. 


84.0 


Usp_PSRolloverPopActuals3 


This routine gets invoked by the usp_PSRollover routine and is responsible for 
populating noms with previous 3 months actuals numbers (primarily used for 

Oil). 


85.0 


Usp PSRolloverPopNoms 


This routine gets invoked by the usp_PSRollover routine and is responsible for 
populating noms with previous months nom numbers. 


86.0 


Usp_pStatusChanged 


This routine gets invoked anytime the production month status is changed 
(Initial, Availability, Sales, Invoiced Accounting, Completed). Other routines are 
invoked depending on the from and to status for the production month. 


87.0 


Usp_w/ 


Any stored procedure that begins with Usp_w_ has been setup as a one time 
only procedure that is used to correct any database items/etc. These 
procedures can be permanently deleted and have no impact on existing 
functions within EMS. 



Application Software 



q Technical Skill Set Required 

?f Support and maintenance of the Energy Management System requires the following technical skill set 



y3 


Ref# 


Skill Set 


Used For... 




1.0 


SQL-Server (Transact SQL) 


All data is stored in MS SQL-Server database tables. This data is accessed via direct SQL 
statements (embedded in windows applications, stored procedures and reports). There are 
several database views that have been setup to access aggregated information (for performance 
and consistency). In addition all of the critical calculations and time consuming procedures (like 
the main EMS calculation, routing and rollover process) are written as Transact-SQL stored 
procedures (and documented in this manual). 




2.0 


Delphi <V5 +) 

(includes Delphi 3 rd party tools) 


All client applications are written using this particular RAD tool.* In addition to knowing the 
standard components that come with this tool, any of the 3* party toots (documented in this 
manual) are used extensively. See the 3™ party tools listed in the Tools Utilized* section for more 
details. 


I : f 


3.0 


Crystal Reports (V8.0) 


All reporting within EMS is done utilizing this toot from Seagate software. 



f«3 

0 Client, Server Applications w/Tools Utilized 

. This particular section contains the high level documentation relative to the Energy Management System software 
application. Each item documented is uniquely numbered to aid in reviews and/or future modifications. 



Ref# 


Item 


Response 


-Comments':- • ■ ■ | 


1.0 


Client Application 


Energy Management 
System 


The Energy Management System is written in Delphi 5 
(service pack 3 applied). Third party controls and 
components were used in the development See other 
areas of this matrix for 3* party tools utilized. 


2.0 


Client Application 


Producer Control 
Center 


The Producer Control Center is written in Delphi 5 (service 
pack 3 applied). Third party controls and components were 
used in the development. See other areas of this matrix for 
3" party toots utilized. This application provides a restricted 
view of information specific to the company/contact that is 
running the application. The data viewed is the same data 
that is maintained in the EMS system. 


3.0 


Server Application 


Software Experts, Inc. 
SECrystat (V8.00) 


All reporting done within EMS utilizes Crystal reports. This 
server application runs and stores all output reports for the 
system. Besides storing an electronic copy of the report 
this server can distribute to a printer, fax folder OR an email 
address if instructed by the EMS application. 


4.0 


Server Application 


Software Experts, Inc. 
SEFax <yZ00) 
(outbound faxing) 


Some output reports (from SECrystal) are designated to be 
faxed. This software is responsible for faxing alt of the 
reports that were designated by EMS to be faxed. 
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Ref# 


Item 


Response 


'Comments: ~;-^v^vW^v-^-^v...^--\ • ■ — 


5.0 


Server Application 


Software Experts, Inc. 
SEServer (VZOOg) 
(database request server) 


All database requests for the Energy Management System 
AND the Producer Control Center go through this database 
server component. This server application typically runs on 
the same machine as the actual database. 


6.0 


3™ Party Tool/Library 


Adobe 

Acrobat Reader (V4.0 +) 


This free tool is used to view reports from EMS. The default 
for all reports is to print them to a PDF format This output 
format is 'overrideable' by the user when the report is 
submitted. Other formats like Excel, Word, Text, eta are 
also supported. 


7.0 


3 ro Party Toot/Library 


Seagate Software 
Crystal Reports (V8.00) 


All reports are written using the Crystal reporting tool from 
Seagate Software). In addition, the report server 
(SECrystal) utilizes the main Crystal reporting FREE runtime 
libraries to run these reports for all EMS client requests. 


80 


3 ro Party Tool/Library 


Dalco Technologies 
DhOvernet A/2 001 


Delphi VCL components that provide internet (TCP/IP) 
access. The SEServer application utilizes this middleware. 


9.0 


3™ Party Tool/Library 


TurboPower Software . . 
Asynch Pro (V3.04) 


The SEFax fax server application utilizes this 3 IU party 
Delphi VCL component list for sending and/receiving faxes. 
The SECrystal reporting server application uses this library 
to write out 'fax ready 1 files. 


10.0 


3 ro Party Tool/Library 


TurboPower Software 
Orpheus (V3.08) 


Many of the online screens for all client and server 
applications utilize the Orpheus controls for screen grid lists, 
combo boxes, etc. The server applications were written with 
this tool set also. 


11.0 


3™ Party Tool/Library 


TurboPower Software 
oyo i ooio \ vo.u&j 


Many of the online screens for all dient and server 
applications utilize the SysTools components for string 
manipulations, spawning tasks, etc. 


12.0 


3™ Party Tool/Library 


Woll2Woll Software 

InfnPnumr OODC\ 1 7 


Many of the online screens for all client and server 
applications utilize these controls for screen grid lists, 
combo boxes, etc. The server applications were written with 
this tool set also. 


13.0 


3™ Party Tool/Library 


Inner Media. Software 
Dynazip (V4.00) 


These are Delphi software components that are for 
compression/decompression of files to and from the server. 
This is used by both the client and server applications. 


14.0 


3 ro Party Tool/Library 


Public Domain 
TEmail(V2.10) 


This is a Delphi software component and is used by the 
client and server applications. It Is responsible for the email 
interface. 


15.0 


3™ Party Tool/Library 


TMS Software 
TwebUpdate (V1.00) 


This is a Delphi software component that provides for 'over 
the internet automatic software upgrades. The client 
applications each utilize this component 


16.0 


3™ Party Tool/Library 


Skyline Software, Inc. 
ImageLib Suite (V5.00) 


These are Delphi software components that provide for 
graphic images displayed within the application. In addition, 
this software provides scanner input capabilities. 



Client Applications, Module List/Descriptions 

This particular section contains the high level documentation relative to each software application module within 
the Energy Management System. Each item documented is uniquely numbered to aid in reviews and/or future 
modifications. The application reference listed below will either indicate EMS (Energy Management System) 
and/or PCC (Producer Control Center). This shows the level of interoperability between these two di nt 
applications. All of these modules are written in Delphi (Object Pascal, (Visual)). 



Ref# 


Module Name 


Module Type 


Application 


Description/Comments 


1.0 


DBAddress 


Data Module 


EMS 
PCC 


This module contains all of the database communication 
components for the Address ('Company and Contact 
Addresses') table. 


2.0 


DBCommonDatabase 


Data Module 


EMS 
PCC 


This module is responsible for setting all of the common 
properties for all other data modules within the system. 
Prior to invoking a query, all other database modules will 
invoke methods within this module to set communication 
ports, maximum number of records, etc. This module also 
stores the actual user id and contains methods for 
accessing this field. 



20F 



Ref#- 
3.0 


Module Name 

DBCommonriiewperouu' <*» 


Module Typo 

Data Module 


Application 

EMS 

PCC 


Description/Comments ; • — 

"This module handles all of the 'flat file" operations 
(compressing/decompressing/etc.) that is involved with the ■ 
applications. Any temporary files that need to be created 
are also controlled by this data module. 


4.0 


DBCompany 


Data Module 


EMS 
PCC 


This module contains all of the database communication 
components for the Company ('Company Information') 
table. ; — 


5.0 


DBContactFunction 


Data Module 


EMS 
PCC 


This module contains all ot the database communication 
components for the ContactFunction ('Roles within their 
r« P Prth/e companies that contacts play") table. 


6.0 


DBContacts 


Data Module 


EMS 
PCC 


" This module contains all of the database communication 
components for the Contacts ('Individual contacts within 
companies') table. , . — . 


7.0 


DBContactGroup 


Data Module 


EMS 
PCC 


This module contains all of the aataoase communication 
components for the ContactGroup (Links contacts to 
arouDs thev may be affiliated with) table. 


8.0 


DBContact_GroupNames 


Udls IV1UUUIG 


EMS 


This module contains all of the database communication 
components for the ContactJSroupNames (table contains 
a record for each group within the system) table. 


9.0 


DBEngine 




EMS 


This module contains all of the database communication 
components for the Engine (contains transaction records 
for each volume inventory transaction item associated with 
the deal) table. „ 


10.0 


DBEngine Jvlaster 


Data Module 


EMS 


This module contains ail of the database communication 
components for the Engine__Master (User enterable pncing 
area 'header* record) table. 


11.0 


DBEngineJvlasterPrice 


Data Module 


"EMS 


This module contains all of the database communication 
components for the EngineJWIasterPrice (User enterable 
pricing area 'detail' records (price tags)) table. 


12.0 


DBEngine_TransactionUst 


Data Module 


EMS 


This module contains all of the database communication 
components for the Engine J"ransactionUst (transaction 
descriptions) table. , 


13.0 


DBExceptionCategories 


Data Module 


"ems 

PCC 


This module contains all of the database communication 
components for the ExceptionCategories ('Reasons for 

Exceptions') table. . 


14.0 


OBExceptionList 


Data Module 


"EMS 
PCC 


"This module contains all of the database communication 
components for. the ExceptionList ('Actual Exception 
Events) table. . . — . 


15.0 


DBGastnv 


Data Module 


"EMS 


This module contains all of the database cornmunicaoon 
components for the Gaslnv (Volume Inventory 'header-) 
table. — : 


16.0 


DBGaslnvD 


Data Module 


1ms 


_ this module contains ail of the database communication 
components for the GaslnvD (Volume Inventory Daily 

'detail') table. . — . 


- 17.0 


DBGCButton 


Data Module 


"ems 

PCC 


This module contains all of the database communication 
components for the GCButton ('Business Functions*) 
security table. . 


18.0 


DBGCtndex 


Data Module 


EMS 
PCC 


This module contains all of the database communication 
components for the GCIndex (Dairy & Monthly Price 
Indices) table. . 


19.0 


DBGCSecurity 


Data Module 


"EMS 
PCC 


" This module contains all of the database communication 
components for the GCSecurrty (Security Authorizations) 
for the applications. 


20.0 


DBGCUser 


Data Module 


EMS 
PCC 


This module contains all of the database xmmunication 
components for the GCUser (User Profiles) table within the 
applications. . . — . 


21.0 


DBImages 


Data Module 


"ems 


This module contains all of the database communication 
components for the SEImages (company logos, eta) table 
within the application. 


21.0 


DBIndexBasketLink 


Data Module 


"ems 

PCC 


"This module contains all of the database communication 
components for the IndexBasketLink (Links actual indices 
to a particular basket) table within the application. 


22.0 


DBIndexBaskets 


Data Module 


"EMS 
PCC 


" This module contains all of the database communication 
components for the IndexBaskets (Grouping of indices to 
be used in a 'simple* averaging calculation) table within the 
application. 
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Ret # : 




Module Tvofi 


■ Annlication 


Description/Comments^ ■ . • - - ; 


23.0 


DBIndexRef 


Data Module 


EMS 
PCC 


This module contains all of the database-communication 
components for the IndexRef (Each price index within the 
system contains a record entry here) table within the 
application. 


24.0 


DBK 


Data Module 


EMS 


This module contains all of the database communication 
components for the K (Contracts table within the 
application). 


25.0 


DBKNetBack 


Data Module 


EMS 


This module contains all of the database communication 
components for the KNetBack (Contracts Netback 
Percentaqe Tiers) table within the application. 


26.0 


DBKNotes 


Data Module 


EMS 


This module contains all of the database communication 
components for the KNotes (Contract Notes) table within 
the application. 


27.0 


DBKProducts 


Data Module 


EMS 


This module contains all of the database communication 

Mitmnnonk fnr thft KPrnduei*. /nmdijcts that am available 
COrnporicniS mi uki i\riwuuua ypiuuuMS ll la l oi tJ avouaww 

within contracts) table within the application. 


28.0 


DBKReportDefaults 


Data Module 


EMS 


This module contains all of the database communication 

f^mnnnontc far the KR AnnrtflpfaiJlte /standard r*»nnrt 
COmpUilcllw i \Ji ii ic ivtcpui iwuiauiw \vU3i luai u ic^uii 

defaults) table within the application: 


29.0 


DBKReportOverrides 


Data Module 


EMS 


This module contains all of the database communication 

MimnnnentQ fnr the KReDOrtOvArridA* fctanriarri rftnort 

overrides for a contract) table within the application. 


30.0 


DBKServices 


Data Module 


EMS 


This module contains all of the database communication 
components for the KServices (services that are available 

■iiithin s^nfrafte) tahlA within thn annlicstinn 


31.0 


f DBLeg 


Data Module 


EMS 


This module contains all of the database communication 
components for the Leg (available routes and rates for the 

nm^ns-ti/tn mnnth\ tahlA within thft nnnlir^atinn 
prOQucilon rnuniii/ louto wiuuii uio apfjin«ouufi. 


32.0 


OBLegD 


Data Module 


EMS 


This module contains all of the database communication 
components for the LegD (available DAILY routes and 

m*a* ix r tha nmHnrttnn\ tahlA within thA nrtnltcatton 
rgteS TOT ulc prouui^UUIIJ la UIO will ill I uic auuiibaliuii. 


33.0 


DBLeg Detail 


Data Module 


EMS 


This module contains all of the database communication 
components for the Leg Detail (specific routing instructions 

n ii wMinmnc niin**hacA*4 anri cnlrfl tsblA within thA 
lOr ail VOIUITtcS puiuiaaou ofiu auiu/ uiuic mil mi uio 

application. 


34.0 


DBLegRef 


uata MOGuie 


cMo 


J 1 1 IUU UlC? V r\ ' 1 IIQII 1^ Q II wl ulv \4 W m t/gww iwl I H I iui Mi*»*twi i 

components for the LegRef (master list of routes and rates) 
table within the application. 


35.0 


DBLocations 


uata Moauie 


cMo 
PCC 


| iTlvUUIC? wwlllAlllw Olt wl lire W v w wvi i ii i imi iivumwi i 

components for SELocations (locations) table within the 
application. 


36.0 


DBMessages 


Data Module 


CMC 

PCC 


This module contains all of the database communication 
components for the SEMessages (system messages) table 
within the application. 


37.0 


DBMeter 


Uala MOUUlO 


CJYIO 


This module contains all of the database communication 
components for the Meter/Well table within the application. 


36.0 


DBMeterAllocations 


Data Module 


EMS 


This module contains all of the database communication 
components for the MeterAllocations (ownership interests 
in volume from a meter/well) table within the application. 


39.0 


DBMeterNotes 


Data Module 


EMS 


This module contains all of the database communication 
components for the MeterNotes table within the 
application. 


40.0 


DBMeterRates 


Data Module 


EMS 


This module contains ail of the database communication 
components for the MeterRates (pressure base, Btu factor, 
etc. from a meter/well) table within the application. 


41.0 


DBMiscQueries 


Data Module 


EMS 
PCC 


This module contains all of the miscellaneous queries that 
were created to enable views of various tables within the 
application. 


42.0 


DBPackage 


Data Module 


EMS 


This module contains all of the database communication 
components for the Package (Deals) table within the 
application. 


43.0 


DBPackageCorrespondence 


Data Module 


EMS 


This module contains all of the database communication 
components for the PackageCorrespondence (electronic 
copies of documents associated with deals) table within 
the application. 
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Ref# 

44.0 


Module Name. 
DBPackageCosts 


Module Type 

Data Module 


Application 

EMS 


Description/Comments: .."«: 1, :-v?v --v.V 
This module contains all of the databaaetximmunication 
components for the PackageCosts ('Other Costs' 
associated with deals) table within the application. 


45.0 


DBPtpeField 


Data Module 


EMS 


This module contains all of the database communication 
components for the PipePield (Pipe/Field information) table 
within the application. 


46.0 


DBPriceComponents 


Data Module 


EMS 


This module contains all of the database communication 
components for the PriceComponents (tags to associate to 
each portion of a price) table within the application. 


47.0 


DBPriceDesc 


Data Module 


EMS 


This module contains all of the database communication 
components for the PriceDesc (Deal free form price 
description) table within the application. 


48.0 


DBPrinterDef 


Data Module 


EMS 


This module contains ail of the database communication 
components for the PrinterDef (printer definitions) table 
within the application. 


49.0- 


I DBProcessingCodes 


Data Module 


EMS 
PCC 


This module contains all of the database comrnuntcauon 
components for the SEProcessingCodes (reference code 
description) table within the application. 


50.0 


DBProcessingCodeTyes 


Data Module 


EMS 


This module contains all of the database communication 
components for the SEProcessingCodeTypes (type codes 
that classify sets of reference codes) table within the 
application. 


51.0 


DBProducerMessage 


Data Module 


PCC 


This module contains all of the database communication 
components for the ProducerMessage (dynamic messages 
posted to producers) table within the application. 


52.0 


DBP rod Interest 


Data Module 


EMS 


This module contains all of the database communication 
comoonents for the Prodlnterest (Availability royalty 
interests) table within the application. 


53.0 


DBProdPKG 


Data Module 


EMS 


This module contains all of the database communication 
components for the ProdPKG (Availability deal ID to 
ProdVol cross reference) table within the application. 


54.0 


DBProdSum 


Data Module 


EMS 


This module contains all of the database communication 
components for the ProdSum (Availability summary totals 
by meter/well) table within the application. 


55.0 


DBProdVol 


Data Module 


EMS 


This module contains all of the database communication 
components for the ProdVol (Availability detail owner 
interest totals by meter/well) table within the application. 


56.0 


DB rDealClass 


Data Module 


EMS 


This module contains ail of the database communication 
components for the rDealClass (All of the available deal 

classifications) table within the application. 


57.0 


DBrOealClassA 


Data Module 


EMS 


This module contains all of the database communication 
components for the rDealClassA (all possible answers 
available to the deal class rules (rDealClass table)) table 

within the application. 


58.0 


DBrDealClassRules 


Data Module 


EMS 


This module contains all of the database communication 
components for the rOealClassRules (all rules associated 
with every combination of deal classification) table within 
the application. 


59.0 


DBrGasMonth 


Data Module 


EMS 
PCC 


This module contains ail of the database communication 
components for the rGasMonth (an entry exists here for 
every possible month within the system, with status 
information) table within the application. 


60.0 


DBRptsCorrtrol 


Data Module 


EMS 
PCC 


This module represents the main driver module for 
submitting reports. 


61.0 


DBRptsExecutedStats 


Data Module 


EMS 
PCC 


components for the SERptsExecutedStats (Execution 
statistics for reports) table within the application. 


62.0 


DBRptsGroupltems 


Data Module 


EMS 
PCC 


This module contains all of the database communication 
components for the SERptsGroupltems (List of reports 
available within each tab/folder) table within the 
application. 


63.0 


DBRptsGroups 


Data Module 


EMS 
PCC 


This module contains all of the database communication 
components for the SERptsGroups (List of all tabs within 
each reporting folder) table within the application. 
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,ReHM 


Module Name 


Module Typo 


Application 


Description/Comments ■ 


64.0 


DBRptsltemDetail 


Data Module 


EMS 
PCC 


This module contains all of the database-communication 
components for the SERptsltemDetail (List of specific 
reports available throughout all folders and tabs) table 
within the application. 


65.0 


DBRptsltemParms 


Data Module 


EMS 
PCC 


This module contains all of the database communication 
components for the SERptsltemParms (List of all report 
parameters available to each specific report) table within 
the application. 


66.0 


DBRptsQueue 


Data Module 


EMS 
PCC 


This module contains all of the database communication 
components for the SERptsQueue (actual report 
submission queue) table within the application. 


67.0 


DBRptsQueueOistribute 


Data Module 


EMS 
PCC 


This module contains all of the database communication 
components for the SERptsQueueDistribute (report 
distribution instructions area) table within the application. 


68.0 


DBRptsQueueNotify 


Data Module 


EMS 
PCC 


This module contains all of the database communication 
components for the SERptsQueueNottfy (report notification 
instructions area) table within the application. 


so n 

□9.U 


nRDntc^rhf^rtiilp 

UDMpidwUICUUIC 


Data Module 


EMS 
PCC 


This module contains all of the database communication 
components for the SERptsSchedule (report schedule 
definition area) table within the application. 


70.0 


DBRptsScheduledReports 


Data Module 


EMS 
PCC 


This module contains all of the database communication 
components for the SERptsScheduledReports (reports 
belonging to schedule definition area) table within the 
application. 


71.0 


DBRptsScheduleGroups 


Data Module 


EMS 
PCC 


This module contains all of the database communication 
components for the SERptsScheduteGroups (report 
schedule groups definition area) table within the 
application. 


7Z0 


OBRptsScheduleUserGroups 


Data Module 


EMS 
PCC 


This module contains all of the database communication 
components for the SERptsScheduleUserG roups (user list 
belonging to a specific schedule group definition area) 
table within the application. 


73.0 


DBRptsTablesUsed 


Data Module 


EMS 
PCC 


This module contains all of the database communication 
components for the SERptsTablesUsed (tables* views and 
stored procedures used by each report area) table within 
the application. 


74.0 


DBStoredProcedures 


Data Module 


EMS 
PCC 


This module contains all of the database communication 
components for accessing and invoking all stored 
procedures and functions on the application. Each of 
these procedures are setup as methods within this class 
and this particular class acts as a common wrapper for 
invoking these DB procedures. 


75.0 


RTCrystalDriverParseMemo 


Business Rules 


EMS 
PCC 


This module contains all of the string parsing routines used 
to store reporting parameters, formulas and selection 
criteria. 


76.0 


RTDBAddress 


Business Rules 


EMS 
PCC 


All business rules and edits associated with the application 
addresses (Address table) are within this particular 
module. 


77.0 


RTDBCompany 


Business Rules 


EMS 
PCC 


All business rules and edits associated with the application 
companies (Company table) are within this particular 
module. 


78.0 


RTDBContactFunction 


Business Rules 


EMS 
PCC 


All business rules and edits associated with the application 
contact function (ContactFunction table) are within this 
particular module. 


79.0 


RTDBContacts 


Business Rules 


EMS 
PCC 


All business rules and edits associated with the application 
contacts (contacts table) are within this particular module. 


80.0 


RTDBContact_Group 


Business Rules 


EMS 
PCC 


All business rules and edits associated with the application 
contact group relationships (ContactGroup table) are within 
this particular module. 


81.0 


RTDBContact_GroupNames 


Business Rules 


EMS 


All business rules and edits associated with the application 
contact group names (Contact.GroupNames table) are 
within this particular module. 


82.0 


RTDBEngine 


Business Rules 


EMS 


All business rules and edits associated with the application 
engine pricing transaction (Engine table) are within this 
particular module. 
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Ret # 

83.0 


RTDBEngine_Master 


Module Type 

Business Rules 


Application 
EMS 


Description/Comments. •-••^ 
All business rules and edits associated with the application 
engine pricing entry (Engine_Master table) are within this 
particular module. 


84.0 


RTDBEngine_MasterPrice 


Business Rules 


EMS 


All business rules and edits associated with the application 
engine pricing components (w/price tags) entry 
(EngineJYIasterPrice table) are within this particular 
module. 


85.0 


RTDBEngine_TransactionList 


Business Rules 


EMS 


All business rules and edits associated with the application 
engine transaction master list (EngineJTransactionUst 
table) are within this particular module. 


86.0 


RTDBExceptionCategories 


Business Rules 


EMS 
PCC 


All business rules and edits associated with the application 
exception categories (ExceptionCategories table) are 
within this particular module. 


87.0 


RTDBExceptionList 


Business Rules 


EMS 
PCC 


All business rules and edits associated with the application 
exception list (ExceptionList table) are within this particular 
module. 


88.0 


RTDBGaslnv 


Business Rules 


EMS 


All business rules and edits associated with the application 
volume inventory transaction header (Gaslnv table) are 
within this particular module. 


89.0 


RTDBGaslnvD 


Business Rules 


EMS 


All business rules and edits associated with the application 
volume inventory transaction detail daily (GaslnvD table) 
are within this particular module. 


90.0 


RTUDoUoUaOn 




EMS 
PCC 


All business rules and edits associated with the application 
business functions (GCButton table) are within this 
particular module. 


91.0 


KTUouOinaex 


Rusinps<* Rules 


EMS 
PCC 


All business rules and edits associated with the application 
price indices (GCIndex table) are within this particular 
module. 


92.0 


RTDBGCSecurity 


Rusiness R nl An 


EMS 
PCC 


All business rules and edits associated with the application 
security authorizations (GCSecurity table) are within this 
particular module. 


93.0 


DTnonri leer 


Business Rules 


EMS 
PCC 


All business rules and edits associated with the application 
users (GCUser table) are within this particular module. 


94.0 


RTDBImages 


Business Rules 


EMS 


All business rules and edits associated with the application 
graphic images (SEImages table) are within this particular 
module. 


95.0 


□THDInHovDaelratl inlf 


Business Rules 


EMS 
PCC 


All business rules and edits associated with the application 
index price basket link (IndexBasketUnk table) are within 
this particular module. 


90.U 


□TnninHavRaetrAtc 


Business Rules 


EMS 
PCC 


All business rules and edits associated with the application 
index price baskets (IndexBaskets table) are within this 
particular module. 


O.T ft 

97. U 


DTTtRlnHovRof 

K I uoinaexr\ei 


Business Rules 


EMS 
PCC 


All business rules and edits associated with the application 
price index master list (IndexRef table) are within this 
particular module. 


Qft rt 


PTnRK 
n i udi\ 


Business Rules 


EMS 


All business rules and edits associated with the application 
contracts (K table) are within this particular module. 


99.0 


RTDBKNetBacK 


Business Rules 


EMS 


All business rules and edits associated with the application 
contract netback pricing tiers (KNetBack table) are within 
this particular module. 


100.0 


RTDBKNotes 


Business Rules 


EMS 


All business rules and edits associated with the application 
contract free form note area (KNotes table) are within this 
particular module. 


101.0 


RTDBKProducts 


Business Rules 


EMS 


All business rules and edits associated with the application 
contract products area (KProducts table) are within this 
particular module. 


102.0 


RTDBKReportDefaults 


Business Rules 


EMS 


All business rules and edits associated with the application 
contract standard report defaults area (KReportOefautts 
table) are within this particular module. 


103.0 


RTDBKReportOvemdes 


Business Rules 


EMS 


All business rules and edits associated with the application 
contract standard report overrides area (KReportOvemdes 
table) are within this particular module. 


104.0 


RTDBKServices 


Business Rules 


EMS 


All business rules and edits associated with the application 
contract services area (KServices table) are within this 
particular module. 
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Ref# 


Module Name 


Module Type ' 


Application 


- Description/Comments; — ■>■ 


105.0 


RTDBLeg 


Business Rules 


EMS 


All business rules and edits associated with the application 
leg (monthly) area (Leg table) are within this particular 
module. 


106.0 


RTDBLegD 


Business Rules 


EMS 


All business rules and edits associated with the application 
leg (daily) area (LegO table) are within this particular 
module. 


107.0 


RTDBLegDetail 


Business Rules 


EMS 


All business rules and edits associated with the application 
leg detail (main routing) area (LegOetail table) are within 
this particular module. 


108.0 


RTDBLegRef 


Business Rules 


EMS 


All business rules and edits assoaated with the application 
leg master list area (LegRef table) are within this particular 
module. 


109.0 


RTDBLocations 


Business Rules 


EMS 
PCC 


All business rules and edits associated with the application 
locations (SELocations table) are within this particular 
module. 


110.0 


RTDBMessages 


Business Rules 


EMS 
PCC 


All business rules and edits associated with the application 
messages (SEMessages table) are within this particular 
module. 


111.0 


RTDBMeter 


Business Rules 


EMS 


All business rules and edits associated with the application 
meters (Meter table) are within this particular module. 


• 112.0 


• RTDB Mete rAllocat ions 


Business Rules 


EMS 


All business rules and edits associated with the application 
meter ownership allocations (MeterAllocations table) are 
within this particular module. 


113.0 


RTDBMeterNotes 


Business Rules 


EMS 


All business rules and edits associated with the application 
meter comment areas (MeterNotes table) are within this 
particular module. 


114.0 


RTDBMeterRates 


Business Rules 


EMS 


All business rules and edits associated with the application 
meter rate areas (MeterRates table) are within this 
particular module. 


115.0 


RTDBPackage 


Business Rules 


EMS 


All business rules and edits associated with the application 
deals (Package table) are within this particular module. 


116.0 


RTDBPackageCorrespondence 


Business Rules 


EMS 


' All business rules and edits associated with the application 
deal correspondence (PackageCorrespondence table) are 
within this particular module. 


117.0 


RTDBPackageCosts 


Business Rules 


EMS 


All business rules and edits associated with the application 
deal 'Other Costs' (PackageCosts table) are within this 
particular module. 


118.0 


RTDBPipe Field 


Business Rules 


EMS 


All business rules and edits associated with the application 
pipes/fields (PipeReld table) are within this particular 
module. 


119.0 


RTDBPriceComponents 


Business Rules 


EMS 


All business rules and edits associated with the application 
price components (PrlceComponents table) are within this 
particular module. 


120.0 


RTD B P nceDesc 


Business Rules 


EMS 


All business rules and edits assoaated with the application 
deal pricing free form text area (PriceOesc table) are within 
this particular module. 


121.0 


RTOBPrinterOef 


Business Rules 


EMS 


All business rules and edits assoaated with the application 
printer definitions (PrinterOef table) are within this 
particular module. 


122.0 


RTDBProcessingCodes 


Business Rules 


EMS 
PCC 


All business rules and edits associated with the application 
processing codes (SEProcessingCodes table) are within 
this particular module. 


123.0 


RTDBProcessingCodeTypes 


Business Rules 


EMS 


All business rules and edits associated with the application 
processing code types (SEProcessingCodeTypes table) 
are within this particular module. 


124.0 


RTDBProdlnterest 


Business Rules 


EMS 


All business rules and edits associated with the application 
'Availability* royalty interests (Prodlnterest table) are within 
this particular module. 


125.0 


RTDBProdPKG 


Business Rules 


EMS 


All business rules and edits associated with the application 
'Availability' deal to ProdVol cross-reference (ProdPKG 
table) are within this particular module. 


126.0 


RTDBProdSum 


Business Rules 


EMS 


All business rules and edits associated with the application 
'Availability' monthly meter summary (ProdSum table) are 
within this particular module. 


127.0 


RTDBProdVol 


Business Rules 


EMS 


All business rules and edits associated with the application 
'Availability' monthly ownership volume (ProdVol table) are 
within this particular module. 
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Ref# 


Module Name? .v>-» 


Module Type 


Application 


-Description/Comments^ •> ■^■^^-•^ ■•■^y ; : 


128.0 


RTDBrOealClass 


Business Rules 


EMS 


All business rules and edits associated with the application 
deal classification options (rDeaiClass table) are within this 
particular module. 


129.0 


RTDBrDealClassA 


Business Rules 


EMS 


All business rules and edits associated with the application 
deal classification answers (rOealClassA table) are within 
this particular module. 


130.0 


RTOBrOealClassRules 


Business Rules 


EMS 


All business rules and edits associated with the application 
deal classification wasp rules (rOealClassRules table) are 
within this particular module. 


131.0 


RTDBrGasMonth 


Business Rules 


EMS 
PCC 


All business rules and edits associated with the application 
production month (rGasMonth table) are within this 
particular module. 


132.0 


RTDBRptsExecutedStats 


Business Rules 


EMS 
PCC 


All business rules and edits associated with the application 
execution statistics for reporting (SERptsExecutedStats 
table) are within this particular module. 


133.0 


RTDBRptsGroupltems 


Business Rules 


EMS 
PCC 


All business rules and edits associated with the application 
tab items for reporting (SERptsGroupltems table) are 
within this particular module. 


134.0 


RTDBRptsGroups 


Business Rules 


EMS 
PCC 


All business rules and edits associated with the application 
tabs for reporting (SERptsGroups table) are within this 
particular module. 


135.0 


RTDBRptsltemDetail 


Business Rules 


EMS 
PCC 


All business rules and edits associated with the application 
report files used for reporting (SERptsltemDetail table) are 
within this particular module. 


136.0 


RTDB Rots Item Pa rms 


Business Rules 


EMS 
PCC 


All business rules and edits associated with the application 
report file parameters used for reporting 
(SERptsltemParms table) are within this particular module. 


138.0 


RTDBRptsQueue 


Business Rules 


EMS 
PCC 


All business rules and edits associated with the application 
report submission queue used for reporting (SERptsQueue 
table) are within this particular module. 


139.0 


RTDBRptsQueueDistribute 


Business Rules 


EMS 
PCC 


All business rules and edits associated with the application 
report queue distribution options used for reporting 
(SERptsQueueDistribute table) are within this particular 
module. 


140.0 


RTDBRptsQueueNotify 


Business Rules 


EMS 
PCC 


All business rules and edits associated with the application 
report queue submission notifications used for reporting 
(SERptsQueueNotify table) are within this particular 
module. 


141.0 


RTDBRptsSchedule 


Business Rules 


EMS 
PCC 


All business rules and edits associated with the application 
report schedules used for reporting (SERptsSchedule 
table) are within this particular module. 


142.0 


RTDBRptsScheduledReports 


Business Rules 


EMS 
PCC 


All business rules and edits associated with the application 
report schedule actual reports used for reporting 
(SERptsScheduledReports table) are within this particular 
module. 


143.0 


RTDBRptsScheduleGroups 


Business Rules 


EMS 
PCC 


All business rules and edits associated with the application 
report schedule groups used for reporting 
(SERptsScheduleGroups table) are within this particular 
module. 


144.0 


RTDBRptsSchedulellserGroups 


Business Rules 


EMS 
PCC 


All business rules and edits associated with the application 
report schedule users (in groups) used for reporting 
(SERptsScheduleUserG roups table) are within this 
particular module. 


145.0 


RTDBRDtsTablesUsed 


Business Rules 


EMS 
PCC 


All business rules and edits associated with the application 
report tables used for reporting (SERptsTablesUsed table) 
are within this particular module. 


146.0 


RTMessageStacfcClient 


Business Rules 


EMS 
PCC 


This particular module is responsible for maintaining the 
current list of messages that will be displayed to the user. 
This module will provide for the storing of up to SO 
messages (in memory tables) in between enter button or 
mouse clicks. This provides for any/all error messages 
concerning a specific event to be displayed at once versus 
one at a time. 


147.0 


FmAbout 


Form 


EMS 
PCC 


This form provides descriptive information about the 
application (version number, copyright notice, email and 
website support links, etc). 
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Ref# 


Module-Name* 


Module Type 


Application 


' Description/Comments- ^ -^ : ^: i: s , 


146.0 


FmActualizePurchases 


Form 


EMS 


This form provides the method for performing (Step 2 of 4) 
of the actualization process within EMS. 


149.0 


FmActualizeSales 


Form 


EMS 


This form provides the method for performing (Step 3 of 4) 
of the actualization process within EMS: 


150.0 


FniAddressDetail 


Form 


EMS 


This form provides for the updating of addresses for 
contacts and companies. The table that gets updated 
behind the scenes is the Address table. 


151.0 


FmAddressList 


Form 


EMS 


This form provides a list of all available addresses that 
have already been setup for a company. Options on this 
form include an ability to change, add or delete address 
lines from the list. 


152.0 


FmBusinessFunctionsDetail 


Form 


EMS 


This form provides for the updating of the business 
functions that are available within the Energy Management 
System AND the Producer Control Center. The table that 
gets updated (behind the scenes) is the 'GCButton' table. 


153.0 


FmBusiness Functions List 


Form 


EMS 


This form provides a list of all available business functions 
that are currently within the Energy Management System 
AND the Producer Control Center. Options exist here to 
add, change and delete business functions. Each of these 
business functions represent areas within the application 
for setting system security. 


154.0 


FmCommon 


Form 


EMS 
PCC 


This form provides for all of the common properties used 
by ali forms. This form can be accessed via the main 
menus by selecting system properties. All of the color 
schemes, graphic images, etc. that are used by the system 
are included on this form. At runtime, all other forms within 
the system will invoke public methods within this form to 
set their respective screen fields. 


155.0 


FmCompanyOetail 


Form 


EMS 


This form provides the mechanism for updating detail 
information pertaining to a specific company. This includes 
identification of a primary company address. 


156.0 


FmCompanyList 


Form 


EMS 


This form provides a grid list of all companies that are 
currently stored on EMS. Options on this form include 
extensive lookup and tab options. 


157,0 


FmContactDetail 


Form 


EMS 


This form provides the form for updating detail information 
about a contact at a particular company. This includes 
group memberships, functions, etc. 


158.0 


FmContactFunctionDetaii 


Form 


EMS 


This form provides the mechanism for associating a 
contact within a company to a specific job function at that 
company (i.e. Accounting, production, etc). 


159.0 


FmContactGroupOetail 


Form 


EMS 


This form provides the mechanism for creating or updating 
contact groups on the system. 


160.0 


FmContactGroupUst 


Form 


EMS 


This form lists all available contact groups on the system. 
Options on this form include the ability to add, change or 
delete a contact group. 


161.0 


FmContactUst 


Form 


EMS 


This for lists all contacts within all companies. Options on 
this form include an ability to add, change or delete a 
specific contact (with appropriate security). In addition, 
there are extensive data lookup capabilities. 


162.0 


fmContactSecurityAuth 


Form 


EMS 


This form provides for the entry of external company 
security authorization rules (I.e. Enabling access to 
Producer Control Center, eta). 


163.0 


FmContractOetail 


Form 


EMS 


This form represents the detail form for entering contract 
specific information (netback pricing information, contract 
name, terms, provisions, etc). 


164.0 


FmContractUst 
• 


Form 


EMS 


This form provides a grid list of all existing contracts on the 
system. Options exist on this form to add, change r 
delete a contract This form also includes extensive lookup 
and company letter tab's for searching all contracts. 


165.0 


FmDailyPrices 


Form 


PCC 


This form shows the graphs of the revenue detail 
information on the Producer Control Center. 


166.0 


FmDealClassificationUpdates 


Form 


EMS 


This form provides the mechanism for changing any 
calculation rules associated with a given combination of 
deal classification codes. The WASP inclusion indicator is 
stored on this table. 


167.0 


fmDealCorrespondence Detail 


Form 


EMS 


This form provides an entry form for attaching electronic 
correspondence to a deal. 
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Reft 

iDO.L 


t- Module Name 

) Fm Deal Costs Entry Detail 




mtmssm 

warn 


~| Description/Comments, ^f^:-^^H ; v~-^w 

This form provides for the entry of 'Other-Costs' associated 
with a particular deal. 


169.0 


FmDeaiDetaii 


Form 


EMS 


This is the main detail form that shows all of the 
information relative to a deal. 


170.0 


FmDealEntryNew 




cue 


This form represents a popup box that is displayed when a 
new deal has been requested. This box prompts the user 
for the type of deal (purchase or sale) and what product 
and service it is applicable toward. 


1 7 1.0 


FmDealLJst 




CMg 


This form provides a listing of all 'Purchase' or 'Sales* 
deals within a given month on a grid. Options exist on this 
screen to add. change or delete a deal. 


172.0 


FmDealPrice 

I 


Form 


EMS 
PCC 


This is the form that is used whenever a user wants to 
calculate the prices for a given volume within a given 
month. The only options on this form are to 'Price Air and 
only for those production months and volumes that are 
applicable {based on monthly status). 


173.0 


FmDealPriceEntryDetail 


Form 


EMS 


This is the main form for entering deal price information 
within the Energy Management System. The primary 
underlying tables that get updated Include Enaine Master 
and Engine MasterPrice. 


174.0 


FmException ' 


Form 


CMS 

PCC 


This form is invoked whenever a system exceotion occurs 
within the system. In order to complete the exception a 
particular user must have a 'Super ID* for the function and 
he/she must provide an exception reason with a 
description. . 


175.0 


FmExceptionCategoriesDetail 


Form 


EMS 


This form provides for a detail update screen to update 
[ reason code information for a given type of exception. 


176.0 


rmtxceptionuategonesUst Form 


EMS 


This form provides a listing grid of all reason code 
exceptions for a given type of exception. 


177.0 

4 70 n 




Form 


EMS 


This form provides an ability to view graphic images and/or 
scan in graphic images from a scanner. These images can 
be attached to a deal. 


178.0 


fmGroupMemberDetaii ~ 


Form 


EMS 


This form represents the detail form for associating a 
contact as a member of a specific group. 


179.0 


FmlmagesDetail 


Form 


EMS 


This form represents the detaH form used for posting 
updates to the application graphic images (logo's, etc.). 




FmlmagesList 


Form 


EMS 


This form provides a list of all graphic. images (logos) that 
are currently stored in the system. 


161.0 


FmlndexBasketDetail 


Form 


EMS 


This form provides a detail update screen to update index 


182.0 


FmlndexBasketUnkDetaii 


Form 


1ms 


This form provides a detail update form to allow for the 
updating of index links to particular baskets. 


183.0 


FmlndexBasketList 


Form 


EMS 


This form provides a listing grid of aU index baskets on the 
system. 


184.0 


FmLegDailyOetail 


Form 


EMS 


This form provides the detail rate information associated 
with a dairy leg rate (which overrides the monthly rate 
when setup on EMS). 




FmLegDailyList 


Form 


EMS 


This form provides a listing of all dairy rates that may be 
setup for a particular leg. 


186.0 
1A7 n 


FmLegDetaii 


Form 


EMS 


This form provides the detail rate information fl«fffmated 
with the a given leg, on a given production month within 
the system. Both nomination and actual rate information is 
available. ^^^^ 


IO/.U 


FmLegHistory 


Form 


EMS 


This form provides a historical list of all monthly tog rates 
that have been established for a given tog. 


188.0 


FmLegList 


Form 


EMS 


This form provides a list of all legs on the system. Options 
exist from this screen to select and change (modify) the 
specific rate information about a leg. 


189.0 


FmLegMonthlyView 


Form 


EMS 


This form represents a View form that provides a read- 
onry view or au volumes transported in, out sold and/or on 
balance for a specific meter. 


190.0 


r mLegPurchaseUnkMonthryView 


Form 


EMS 


This form represents a View form that provides a read- 
only view of all the purchase deals (volumes) that have 
>een attributed to a selected sale. 


191.0 1 


"mLegPurchaseUnkView 


•orm | 


EMS 

. 


This form represents a View form that provides a read- 
only view of ail purchases linked to a specific sale on a 
3iven day. 
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Module Name: 


.Module Type- 


Applications 


Description/Comments f -^w^ -:>■■• W 


192.0 


FmLegPurchasePointView 


Form 


EMS 


This form represents a View' form that jnovides a read- 
only view of the originating (hop 0) information for any 
given volume that is displayed on the routing screen(s). 


193.0 


FmLegRoute 


Form 


EMS 


This is the main routing screen. Options exist on this 
screen to select pipe/fields, days, noms or actuals, etc. 
With appropriate security a person can transport and/or 
sell volume through this panel. 


194.0 


FmLegSale 


Form 


EMS 


This form is used as a confirm form for posting volume 
balances to a sate. 


195.0 


FmLegSalesView 


Form 


EMS 


This form represents a View* form that provides a read- 
only view of all sales that exist on a given pipe/field for 
either a single day or an entire month. 


196.0 


FmLegTransport 


Form 


EMS 


This form is used as a confirm form for transporting 
volumes to other meters (pools). Options also exist on this 

form to «iplf*eti\/eh/ nvnrnrin tran^nort outhprino nvr or fual 

rates associated with the transport 


197.0 


FmLegChange 


Form 


EMS 


This form is used whenever a request Is made to change 
the instructions (either volume or rates) on an existing 

trancnnrt OR qsiIa rotttA rtom 


198.0 


fm Leg Delete 


Form 


EMS 


This form is used whenever a routed volume (either 
transported to a pool or posted to a sale) has been 

requcs icq iv uc uensusu. 


199.0 


FmLocationsOetail 


Form 


EMS 


This form provides a detail update form to allow for the 

iinHatinn nf Inflation irifimngtinn l r>MR Inflation Jtntrinv 

are used throughout the system (versus hardcoding 
locations within the software). 


200.0 


fm Locations List 


Form 


EMS 


This form provides a list form to allow for showing the 

Irratinn information Thiwuk logntioo <wilrij» Am ii*jm4 

throughout the system (versus hardcoding locations within 
the software). 


201.0 


fmLogin 


Form 


EMS 
PCC 


This is the common login form used by the application(s). 
It provides the mechanism for authenticating users or 

mmnanv mninffa. i inon Aftrrv into Inn MuaJwiti 

company wniowa uvvii nnuy miu uio oysioin. 


202.0 


fmLoginChange 


Form 


EMS 


This form provides the users of the system with the ability 
to change their login passwords. 




fi til nntrun 
HIlUUQMjp 


Form 


PMC 
CMS 

PCC 


I nis lorm pruviuos a otanuaiu touKuf) aiaiog inai allows tux 

queries to be run for nearly all other list forms within the 
svstem Most fist senssns orovide a lonkuo button 
(binoculars) that will Invoke this form. 


204.0 


frnMessaaeBox 


Form 


EMS 
PCC 


This form disolavs all svstsfn mftssaafts h«*h within ths 
system. This particular form gets utilized by neariy all 
other form on the system. The messages displayed by this 
form include all ERROR, CONFORMATIONAL, 
INFORMATIONAL and IN-PROCESS oriented messages. 


205.0 


fmMeterAllocationsDetatJ 


Form 


EMS 


This form provides for an entry screen for entering 
allocation companies and accounting cross reference deck 
codes for a given meter/well and effective date. 


206.0 


FmMeterDetail 


Form 


EMS 


This form provides for a detail update form on meter/well 

information within the system. 


207.0 


fmMeterUst 


Form 


EMS 


This form provides for a list form of all meters/wells within 
the system. 


208.0 


fmMeterRatesDetail 


Form 


EMS 


This form provides for an entry screen for entering rates 
(pressure base, Btu factor, pipe/field pressure base, etc.) 
for a given meter/well on a specific effective date. 


209.0 


FmMeterRevenue 


Form 


PCC 


This form provides a meter/well form that shows graphic 
representation of calculated volumes and prices. 


210.0 


FmMeterTotalsView 


Form 


EMS 


This form provides a View 1 which is a read-only view of all 
the meter totals (actualized versus not actualized) for an 
entire month). A specific deal OR all deals within a month 
can be viewed through this form. 


211.0 


FmMonthtyStatusDetail 


Form 


EMS 


This form provides a screen for updating the detail 
production month status information. This is where users 
will go to change the status for each production month 
(depending on security level of the user). 
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Description/Comments: 

This form provides a grid list of ail monthly status 
information (by status). Options exist here to invoke the 
detail update screen to update monthly status information 
(with appropriate security). 



fmNetBackTierDetail 



Form 



EMS 



This form provides the detail form for updating the netback 
pricing tiers for a given contract These tiers are 
referenced (for all WASP classified deals) during th 
pricing function. 



Form 



EMS 



This form provides an entry form for specifying the 
parameters used to create the OGIS journal entry and 
revenue receivable accounting feeds. The actual text files 
are created from this form. 



215.0 



FmPickACompany 



Form 



EMS 
PCC 



FmPickAContact 



Form 



EMS 



This form provides a common mechanism for displaying a 
list of companies to a user and having one of them 
selected and carried back to the requesting form. 



This form provides a common mechanism for displaying a 
list of contacts to a user and having one of them selected 
and carried back to t he requesting form. 



Form 



EMS 



This form provides a common mechanism for displaying a 
list of contracts to a user and having one of them selected 
and carried b ack to the requesting form. 



CO 
i0 



Form 



EMS 



This form provides a common mechanism for displaying a 
list of deals to a user and having one of them selected and 
carried back to the requesting f orm. 



Form 



EMS 



This form provides a common mechanism for displaying a 
list of deal meters to a user and having one of them 
selected and carried b ack to th e requesting farm. 



FmPfckALeg 



Form 



EMS 



This form provides a common mechanism for displaying a 
list of leg (monthly routes) to a user and having one of 
them selected and carried back to the i 



RJ 



221.0 FmPickALegRef 



Form 



EMS 



This form provides a common mechanism for displaying a 
list of LegRef (master routes) to a user and having one of 
them selected and earned back to the requesting farm. 



FmPickALegSale 



Form 



EMS 



This form provides, a common mechanism for displaying a 
list of sales points available for routing to a user and 
having one of them selected and carried back to the 
requesting form. 



Form 



EMS 



This form provides a common mechanism for displaying a 
list of meters/wells to a user and having one of them 
selected and carried b ack to the requesting form. 



FmPickAPipeline 



Form 



EMS 



This form provides a common mechanism far displaying a 
list of pipe/fields to a user and having one of them selected 
and carried ba ck to th e requesting form. 



fmPickAReport 



Form 



EMS 



This form provides a common mechanism for displaying a 
list of reports to a user and having one of them selected 
and ea rned back to th e requesting form. 



FmPipeDetail 



Form 



EMS 



This form provides the detail update form for updating 
pipe/field information on the system. 



fmPipelineActuals 



Form 



EMS 



228.0 



fmPipeList 



Form 



EMS 



This is the main form used for enter actual volumes for 
meters/Wells on the system. The form includes a 
calculator function for propagating the volumes across all 
days for the highlighted meter/well. 



This form provides the list form to show all pipe/fields 
currently defined within the system. Options exist on this 
form to add, update or delete a pipe/field. 



FmPriceComponentsOetail 



Form 



EMS 



This form provides the screen for updating the detail 'price 
tags' that have been setup on the system. These price 
tags allow us to identify the various portions of a sale or 
>urchase price. 



FmPriceComponentsUst 



Form 



EMS 



This form provides a grid list of all price components (tags) 
that have been setup on the system. 
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• Module Name- — 


Module Type* 


Application 




M 1 .u 


un ~ n i n u c * u f/u a ic3 




EMS 


This form provides a list of all prices for the daily Index 
Prices. When entering this form the default date is set to 
the current date. When prices are being entered on 
'Mondays' there is a 'copy to previous weekend* button 
which will allow for all prices to be propagated back to the 
previous weekend. Monthly index prices are entered on 
day 1 only for a given month. 


232.0 


Fm Price 1 nd ices Deta il 


Form 


EMS 


This form provides a screen for updating the price index 
information on the database (IndexRef table). This 
includes display order, name, etc 


233.0 


frnPriceindicesList 


Form 


EMS 


This form provides an 'updateable' grid list that shows all 
price indices on the system. Options exist here to invoke 
the add/update function (fmPricelndicesOetaH). 


234.0 


fmPricesBylndexUst 


Form 


EMS 
PCC 


This form provides a graphic and tabular view of index 
prices for a given month. 


235.0 


FmPrinterOetail 


Form 


EMS 


This form provides a detail entry form for updating the 
printer information stored on the system. 


236.0 


fmPrinterUst 


Form 


EMS 


This form provides a list form that shows all printers 
currently defined on the system. 


237.0 


FmProcessingCodesDetail 


Form 


EMS 


This form provides the detail form for updating a given set 
of reference (processing codes). 


4WW.U 


CmDrrvAfittinnpAHael tcf 

"mri uucsoing wuocolui 




CMC 


Thin form nmvtdes the list form for showino all of the 
processing codes. Options exist on this form to add, 
update or delete a given code. 




rrnr'rocessingooues' iuv 




CMC 
CIVIQ 


This farm nmvtdes an abilitv to 'nick* o nartiraitar reference' 

code and send it back to the form that invoked the screen. 








cue 

t-JVIO 


TVito fnrm nmvides the detail form for UDdatina a oh/en set 
of processing code types (types of reference codes). 


241.0 


fmProcessingCodeTypesUst 


Form 


EMS 


This form provides the list form for showing all of the 
processing code types. Options exist on this form to add, 
tirviflta nr delete a oven tvoe 


24Z0 


FmProdVolCofirms 


Form 


EMS 


This form provides the mechanism for recognizing volumes 
that were returned by producers. In addition, options exist 
on this form to send out producer confirmations. 


243.0 


r mrfod v oin ist 


Form 


PMC 


This farm nmuiriM a hfcvfoiv list tti mvfirh/ and mnkftun 

percentage interests, by owner, for a given meter/well. 


244.0 


FmProdVolList 


Form 


EMS 


This form provides the mechanism for entering initial 
volumes (expected availability) from producers. Option 
AYt«t an this form to send out d reducer availabHttv estimate 
reports. 


245.0 


FmReportDefaultsDetail 


Form 


EMS 


This form provides a detail screen for setting up the default 
reports that will be used by entity, product and service on 
the system. These reports include invoices, vouchers, 

remittance etc 


246.0 


FmReportDefauttsList 


Form 


EMS 


This form provides a list screen for showing ail of the 
default reports that are setup by entity, product and service 
on the system. These reports include invoices, vouchers, 
remittance, etc. 


Z4/.Q 


rrnKeporiwvemoesL/eiaii 


Form 


CMC 


Tht« fnrm nmviries a detail screen for setting un the 

override reports that will be used by entity, product and 
service on the system ASSOCIATE TO A SPECIFIC 
CONTRACT. These reports include invoices, vouchers, 

fAfflfnSflCfi fitc 

1 Oil HtWl|I^A*f %*m*kt* 


246.0 


FmReportsList 


Form 


EMS 
PCC 


This is the primary form used for displaying a reporting 
folder. Within this folder are all of the reporting tabs' that 
are available. Within each tab are all of the specific reports 
that can be run. A submission, and view button are 
available here. 


249.0 


FmReportsParaemeters 


Form 


EMS 
PCC 


This is the form that is used when entering the various 
parameters when a report to submitted. Defaults are 
automatically supplied and the parameters are listed in a 
grid list format 


250.0 


fmReportsView 


Form 


EMS 
PCC 


This is the main view form for viewing all of the submitted 
reports. Options exist to view the reports specifically 
submitted by a user OR to view the reports that were 
submitted by the scheduler. 
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Ref # ; 


Mod u le Name :TZ&*- ; ^ . 


Module Type 


Applications 


- Description/Cc^mertts*^^^^ 


251.0 


fmSecurityAuthDetail 


Form 


EMS 


This form represents the form for establishing and updating 
security authorizations between users and business 
functions within the Energy Management System. Options 
exist here to allow for users to have NO ACCESS, READ 
ONLY, READ/UPDATE, READ/UPDATE/DELETE or 
SUPER access to a particular area of application. 


252.0 


frnSecurityAuthList 


Form 


EMS 


This form provides a listing of all security authorizations 
that are set for each user on the Energy Management 
System. Options exist on this form to add, update and 
delete specific security authorizations for any given user of 
the system. 


253.0 


FmsRptslnvoice 


Form 


EMS 


This is the primary form used for submitting standard 
invoice reports. 


254.0 


FmsRptsRemittance 


Form 


EMS 


This is the primary form used for submitting standard 
remittance reports. 


255.0 


fmsRptsVoucher 


Form 


EMS 


This is the primary form used for submitting standard 
voucher reports. 


ice n 


rmi ransacuonuciaii 


Form 


EMS 


This form provides for the entry of *Other Cost transactions 
within EMS. Once these transactions are setup in the 
system, then they can be attached to deals and 
calculations will be done against them. 


257.0 


FmTransactionUst 


Form 


EMS 


This form provides a list of all the 'Other Cost transactions 
that have been setup on the system. 


258.0 


fm Use rProfi les Deta i 1 


Form 


CMC 


Thic farm rcmnPQAnta thfi CTBJltion flfld UEXJfitA form for all 

1 lUtTIl IwUf CvONbw lira UvOUvll Ql V\4 WpWOw JUMII 1 VI Oil 

users on the Energy Management System. This form 
provides an administrator with the ability to change name, 
password, title, default printer, etc for all users on the 
system. 


259.0 


fmUserProfilesList 


Form 


EMS 


This form provides a listing of all users that are capable of 
using the Energy Management System. Options exist on 
this form to add, update or delete a specific user. 


260.0 


fmGasControlMainMenu 


Form 


EMS 


This form represents the main menu for the Energy 
Management System. AH menu options, speed buttons, 
etc are stored on this form. Thb particular form is also 
responsible for invoking the methods to establish a 
connection and set the form screen attributes (based on 
user preferences). 


261.0 


trmProducerControlCenterMain 


Form 


PCC 


This form represents the main menu for the Producer 
Control Center. All menu options, speed buttons, etc are 
stored on this form. This particular form is also responsible 
for invoking the methods to establish a connection and set 
the form screen attributes (based on user preferences). 
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APPLICATION (CLIEN-SIDE) SOFTWARE 

The table that follows contains the high-level documentation related to the 
systems and methods provided by the present invention and, in particular, those sub- 
functions and applications that run client-side in the context of the present invention. In 
the table that follows, the terms EMS and PCC are used to differentiate (as described 
above), between a full use application system and a limited use/user/function 
application system that are provided by the present invention. The actual source code 
for such application software is contained among the files found on the attached 
compact disc. 

PRICING AND PRICING TECHNIQUES 

So far in the aforementioned detailed discussion the present invention, it 
has been assumed that the particular pricing techniques may be employed to 
price one or more fuel deals automatically. The present invention certainly 
permits fuel deals to be priced based on a variety of factors germane to the 
energy field. Additionally, the systems and methods provided by the present 
invention permit fuel deals to be priced automatically, in batch or otherwise, 
based on pricing techniques which are modularized and which are carried out 
automatically based on prior or other collections of fuel deals and other fuel 
deal data. Accordingly, teams of sales personnel can have deals priced based 
on company specifications to meet margin requirements, etc. 

One such technique implemented as a modularized process capable of 
pricing one or more fuel deals in accordance with the present invention is 
referred to as the WASP technique which stands for the Weighted Average 
Selling Price technique. WASP permits one or more fuel deals (usually a 
collection) to be priced to meet organization pricing targets (and margin 
requirements) based on computed average sales prices across collections of 
fuel deals. The WASP technique and its supporting computer software are 
contained herein for purposes of example to illustrate the novelty of having a 
system that can incorporate a substitutable pricing technique (algorithm) into a 
business process like or similar to the one depicted in and discussed in regard 
to FIG. 1. 
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The WASP Calculation 

This particular section contains information on the calculation that occurs 
to price deals. In the context of the present invention, it is envisioned that there 
are three situations that can trigger a pricing calculation: 

1. The price calculation can be submitted at any time by individuals 
with appropriate security using the System online pricing screen 
(see FIGS. 4A-4Q). Only those production months in a 'Sales' 
(nomination recalculated) or 'Invoiced' (actual recalculated) status 
can be submitted through this screen; 

2. When the status for a production month goes from 'Sales' to 
Invoiced' a final nomination is performed. In addition, when the 
status of a production month goes from 'Invoiced' to 'Accounting' 
a final actuals calculation is performed. These production month 
status 'promotions' occur through the EMS online screens (by 
individuals with an appropriate level of security); and 

3. Each evening, for example, all production months that are in 
either the 'Sales' or 'Invoice' status will have a calculation cycle 
run for them. This calculation begins at approximately 8:00 CST, 
for example. This ensures that all variables (price index entries, 
volumes, routing instructions, etc.) that could influence the price of 
a given set of deals are recalculated and presented as current, the 
first thing in the morning. 

The entire calculation process is comprised entirely of MS SQL-Server 
Transact-SQL stored procedures. The 'flow' of the calculation can be described 
with reference to the following six (6) stages: 

Stage 1 . Sales Deal Calculations 

Calculate all sales deals first (all pools and deal classifications). This is 
done because knowing the sales prices (by pool) is required for the following 
purchase deal calculations. 
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Stage 2 WASP Peal Preparation 

This particular stage simply prepares the WASPResolvedRouting table 
with initial sales pool total dollars and volumes. This is the primary table that is 
used when repeatedly (such as via iteration) tracing all volumes from the sales 
point back to originating purchase points. 

Stage 3 Purchase Deal 'None' Pool (3 rd Party) Calculations 

All third party purchase deals (belonging to the 'None' (pool) are 
calculated first. The reason for this is because of the potential that some of 
these deals having Financial Overrides that are to be distributed to either a 
'Common' WASP pool OR to a specific deal. By doing these calculations first, 
the profit gain or loss (for the financial overrides) can be determined and posted 
to the appropriate place in the WASPResolvedRouting table. 

Stage 4 Purchase Deal 'Dedicated' Pool (Sanctioned Sales) 
Calculations 

All sanctioned sales purchase deals are now calculated. The price for 
these purchases is driven based on a weighted average basis of the sales 
meters. Sanctioned sale purchase exist in their own pool ('Dedicated') so that 
no other purchases volumes (and sales of those volumes) will impact the price 
calculated. Netback percentages are applied. 

Stage 5 Purchase Deal 'Common' Pool (Equity) Calculations 

All equity deals are then calculated. The price for these purchases is 
driven based on a weighted average basis of the sales meters. All purchases 
that are classified as 'equity' will share in pricing and costing (weighted). The 
pricing is based on the 'common' body. Any given purchase deal classified as 
equity could potentially impact the price that other purchase deals (in the 
'common' pool) calculates. Netback percentages are applied. 
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Stage 6 Transportation Costs 

This stage of the calculation aggregates all of the transport volumes 
throughout the month to special transport deals and volume inventory items. 

Each of the aforementioned stages of the calculation are invoked from a 
stored procedure called usp_PSPriceAutoMonth. FIGS. 5A and 5B illustrate 
the process flows corresponding to these 'stages 1 and the flow of the stored 
procedures (discussed above) invoked during the calculation. The ordering of 
these procedures can be tied back to the stages just described above. Actual 
WASP calculation routines are listed below to aid the reader to completely 
understand the nature using a predetermined pricing technique in accordance 
with the present invention. 

Weighted Average Sales Price Calculation Routines 

The following software routines implement a weighted average sales 
pricing technique that may be incorporated within a computing environment 
such as within a server-side processing system to facilitate fuel deal pricing in 
accordance with a preferred embodiment of the present invention. Accordingly, 
in the context of the instant invention, the following routines provide a 
predetermined pricing technique for pricing fuel deals based on past, present, 
or future deals, or combinations thereof. The following routines are found 
among the files contained on the attached compact disc, and also have been 
commented to assist those of ordinary skill in the art understand the details 
related to actual implementation. 



r Microsoft SQL Server - Scripting */ 

r Server IS1 01 V 

r Database: EMS */ 

r Creation Date 02/13/2001 4:08:41 PM 7 



CREATE PROCEDURE uspJGetlndex( 

©GasMonthX DATETIME, 
@6asDayX DATETIME, 
@IXVARCHAR(15), 

©IndexValuexx DECIMAL(19,6) OUTPUT 
) 
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Name: uspJGetlndex 

Description: Get the most recent index value for a specified price index. 
Inputs: 

GasMonthx - Gas month for lookup 

GasDayx - Preferrable gas day used for lookup 

Ix - Index id 

IndexValuexx - return index value 
History: 

1 1/07/2000 JAMIE Modifications to convert from Watcom-SQL to 
Transact-SQL 



7 

BEGIN 

SELECT ©IndexValuexx = 0 

/* ^ ^ ^ ^ 

* First get the maximum gas day that 

* has been entered for this index 

* id in this particular month. 

7 

SELECT @GasDayX=(SELECT Max(GasDay) FROM GCindex WHERE GasMonth=@GasMonthX AND GasDay<=@GasDayX AND 
lndexlD=@IXANDIndexVal<>0) 

r 



* Now get the index value for that 
*day. 



7 

SELECT ©IndexValuexx = IndexVal FROM GCindex WHERE GasMonth=@GasMonthX AND GasDay=@GasDayX AND lndexlD=@IX 
END 

GO 

SET QUOTEDJDENTIFIER OFF SETANSLNULLS ON 
GO 

SET QUOTEDJDENTIFIER OFF SETANSLNULLS ON 
GO 

CREATE PROCEDURE usp_fGetlndexBasket( 

@GasMonthX DATETIME, 
©GasDayX DATETIME, 
©IndexBasketlDX VARCHAR(15), 
©IndexValuexx DECIMAL(19,6) OUTPUT 
) 

AS 

BEGIN 

r 

Name: fGetlndexBasket 

Description: This function will get the index basket amount for the specified 
month and date. This function will return a simple average of all the non zero 
components within the index for the month and day. 

Inputs: GasMonthX (current gas month), GasDayX (day within month) and 
IndexBasketlDX (IndexBasket unique identifier). 

Outputs: Simple averaged price for the index basket 

History 
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xx/xx/xx (?) CHIP Original Creation. 

04/29/99 JAMIE Modified for WASP 2.10 Release. Structure changes 

made to the Engine and Engine_Master tables. In 

addition, all documentation added. This particular 

portion of the system required extensive changes 

due to the need to store a nom and actual number 

and because all price components are now stored 

off the Engine.MasterPrice table (STID's 8 and 9). 

11/08/2000 JAMIE Converted to transact-sqi. 



7 

r 



* Declare all exceptions, cursors 

* and local variables that will be 

* utilized by this procedure. 

7 

DECLARE IndexBasketLink.Cursor CURSOR LOCAL FORWARD.ONLY STATIC FOR 

SELECT indexlD FROM IndexBaskelink WHERE lndexBasketlD=@lndexBasketlDX 

DECLARE ©yTotalPrice DECIMAL(19,6) 
DECLARE ©yTotallndices INTEGER 
DECLARE ©yTotalPricelnterim DECIMAL(19,6) 
DECLARE ©ylndexlD VARCHAR(12) 

r 



* Initialize all fields here... 



7 

SELECT @yTotalPrice=0 
SELECT @yTotallndices=0 
SELECT @IndexValuexx=0 

r 



* Loop through all of the indices within 

* the index basket. Obtain the price 

* information. 

7 

OPEN IndexBasketLink.Cursor 

FETCH NEXT FROM IndexBasketLink.Cursor INTO ©ylndexlD 
WHILE @@FETCH_STATUS = 0 
BEGIN 

EXECUTE usp.fGetlndex ©GasMonthX.gGasDayX.gylndexlD.gyTotalPricelnterim OUTPUT 
IF @yTotalPricelnterim<>0 
BEGIN 

SELECT @yTotalPrice=@yTotalPrice-^yTotalPricelnterim 

SELECT @yTotallndices=@yTotallndices+1 

END 

FETCH NEXT FROM IndexBasketLink.Cursor INTO ©ylndexlD 

END 

CLOSE IndexBasketLink.Cursor 
DEALLOCATE IndexBasketLink.Cursor 

r 



* Take the simple average of the totals 

* here... 



7 

IF (@yTotalPrice<>0) AND (@yTotallndices<>0) 
BEGIN 

SELECT @lndexValuexx=(@yTotalPrice/@yTotallndices) 

END 

END 
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GO 

SET QUOTEDJDENTIFIER OFF SET ANSLNULLS ON 
GO 

SET QUOTED IDENTIFIER OFF SET ANSLNULLS ON 
GO 

CREATE PROCEDURE uspJGetNetbackPercentage( 

@PIDx INTEGER, 
©GasMonthx DATETIME, 
©TypeNetbackx VARCHAR(12), 
©WhichPricex INTEGER, 
©yNetbackPercentage DECIMAL(19,8) OUTPUT 
) 

AS 

BEGIN 

r 



Name: uspJGetNetbackPercentage 

Description: This function will return the netback percentage that should be applied 
to a particular deal, for a particular month. This netback percentage is based on the 
percentage setup at the contract level for the deal in question. These percentages 
at the contract level (KNetback table) are tiered. There are two methods of deriving 
the percentage. 

Method 0 (All or nothing) - With this method the average daily volume for the month 
will be used to find the appropriate tier (also based on effective date). The netback 
percentage to use will be the FIRST tier setup on the contract whose average daily volume 
does not exceed the total for the gas month on this package. All gas volume for the 
month will use this same percentage (all or nothing). 

Method 1 (Accumulating) - With this method the resulting end percentage that will be 
used is based on volumes within each tier (they are weighted based on their respective 
volumes. The netback percentage that is calculated is based on the wieghted average of 
all percentages, across all tiers using volumes that were applied. 

This particular function will work with Nomination (WhichPricex = 0) and Actual 
(WhichPricex = 1) volumes. In addition, this procedure can return both 'GAS' and/or 
'OIL' (and or any other) netback (via the TypeNetbackx parameter). 



was sent as an input parameter. The WASP indicator is based on the combination of 
deal classifications that have been established for this deal. The default indicator 
is 'N' (ie if classification information can't be found/etc). All combinations of 
deal classifications should be setup. 

Inputs: 

PIDx (package ID) 
GasMonthx (Gas Month) 
TypeNetbackx (type of netback percentage) 
WhichPricex (0=Nominations, 1=Actuals) 

Outputs: 

A single percentage to be applied to the price, representing the netback. 
History: 

05/13/99 JAMIE Original Creation. 

07/22/99 JAMIE Modified to check for a floor amount 
and return that amount if it is greater 
than the calculated amount 
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09/02/1999 JAMIE Modified to sum volumes either across DEAL, CONTRACT 
or COMPANY when determining the correct tier. 



10 



08/21/2000 JAMIE Modifications to only sum volumes within the same 
product (across entities and services). 

1 1/08/2000 JAMIE Converted to Transact-SQL 



* Declare all exceptions, cursors 
15 * and local variables that will be 

* utilized by this procedure. 



*/ 

DECLARE ©zRound INTEGER 
20 DECLARE ©zEntityCID VARCHAR(12) 

DECLARE ©zKProductID INTEGER 
DECLARE ©zKServicelD INTEGER 

DECLARE ©tmpEndDate DATETIME 
25 DECLARE ©tmpMaxEffective DATETIME 

DECLARE @tmpDayslnPeriod INTEGER 
DECLARE @tmpVolumeTotal DECIMAL(19,2) 
^ DECLARE @tmpAccumulatingTotal DECIMAL(19,2) 

yp DECLARE ©tmpPrevBand DECIMAL(19,2) 

s rj 30 DECLARE ©tmpCurrBand DECIMAL(19,2) 

*!: DECLARE ©tmpBandTotal DECIMAL(19,2) 

& DECLARE ©tmpBandWeightPerc DECIMAL(1 9,8) 

DECLARE ©tmpAccumulatingPrice DECIMAL(19,8) 

35 DECLARE ©yNetbackMethod-INTEGER 

a DECLARE ©yNetbackTierLevel VARCHAR(10) 

Li DECLARE @yAveragePerDay DECIMAL(19,2) 

L e DECLARE ©yDailyTotal DECIMAL(19,2) 

i y DECLARE ©yeffective DATETIME 

LJ 40 DECLARE ©ymaxvollevel DECIMAL(19,2) 

ri DECLARE @ynetprice DECIMAL(19,8) 

?Z DECLARE @ynetpricefloor DECIMAL(19,8) 

U DECLARE @yKID INTEGER 

y, DECLARE @yCID VARCHAR(12) 

45 r 

* Get netback method information off the 

* contract. The default will be all or 

* nothing (most common). However, this 
50 * should always be found on the contract. 

* 0 = All or Nothing 

* 1 = Accumulating 
* 

55 * Also, this area of the code sets the 

* default for the netback to zero. 

* In addition, go and get the default 

* netback tier level off the contract 
60 * in order to know at what level to 

* summarize the volumes when 

* performing the calculation. The 

* default is 'DEAL* if it can't be found 

* or if one is not specified. 

65 *** 

*/ 

SELECT @yNetbackPercentage=0 

SELECT @yNetbackMethod=ISNULL((SELECT tier FROM K WHERE KID=(SELECT KID FROM package WHERE PKG=@PIDx)),0) 
SELECT @yNetbackTierLevel=ISNULL((SELECT NetbackTierLevel FROM K WHERE KID=(SELECT KID FROM package WHERE 
70 PKG=@PIDx)):COMPANr) 
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4 



SELECT @yKID=ISNULL((SELECT KID FROM package WHERE PKG=@PIDx),0) 
SELECT @yCID=ISNULL((SELECT CID FROM package WHERE PKG=@PIDx),") 

r 

5 * Get the entity, product and service 

* information off the deal table. There 

* has to be a value on the deal (package) 

* table for each of these... 

10 •/ 

SELECT @zEntityCID=ISNULL((SELECT K.EntityCID FROM Package.K WHERE PKG=@PIDx and K.KID=Package.KID),") 
SELECT @zKProductlD=ISNULL((SELECT KProductID FROM Package WHERE PKG=@PIDx),0) 
SELECT @zKServicelD=ISNULL((SELECT KServicelD FROM Package WHERE PKG=@PIDx),0) 

r 

15 — 

* Now calculate the average volume of 

* gas per day that this particular 

* package has on the system. Remember to 

* use the WhichPrice parameter to determine 
20 * which volume to get. 

* 0=(Nominated Volume) 

* 1=(pipeline actual volume) 

7 

Q 25 EXECUTE usp JLastDay @GasMonthx,@tmpEndDate OUTPUT 

SELECT @tmpDayslnPeriod=(DATEDIFF(day ) @GasMonthx,@tmpEndDate) + 1) 

IF @WhichPricex=0 
03 BEGIN 

iQ IF @yNetbackTierLevel='DEAL' 

3 p 30 BEGIN 

* ' SELECT @tmpVolumeTotal=ISNULL((SELECT SUM(Nom) FROM Gaslnv WHERE 

Q PKG=@PlDx) ( 0) 

L* END 

! IF @yNetbackTierLevel='CONTRACr 

N ; 35 BEGIN 

SELECT @tmpVolumeTotal=ISNULL((SELECT SUM(Gaslnv.Nom) FROM Gaslnv.Package 
WHERE Gaslnv.GasMonth=@GasMonthx AND Gaslnv.DBCR=0 AND 

Gaslnv.PriceType=1 AND Gaslnv.KID=@yKID 

AND Package.PKG=Gaslnv.PKG AND 

40 Package.KProductlD=@zKProductlD) ( 0) 

END 

IF @yNetbackTierLevel='COMPANY' 
BEGIN 

45 SELECT @tmpVolumeTotal=ISNULL((SELECT SUM(Gaslnv.Nom) FROM Gaslnv.Package 

WHERE Gaslnv.GasMonth=@GasMonthx AND Gaslnv.DBCR=0 AND 

Gaslnv.PriceType=1 AND Gaslnv.CID=@yCID 

AND Package.PKG=Gaslnv.PKG AND 

Package.KProductlD=@zKProductlD) p O) 
50 END 
END 

IF @WhichPricex=1 
BEGIN 

IF @yNetbackTierLevel=*DEAL' 
55 BEGIN 



s 



PKG=@PIDx),0) 



SELECT @tmpVolumeTotal=ISNULL((SELECT SUM(PipelineActuals) FROM Gaslnv WHERE 



END 

IF eyNetbackTiertevel='CONTRACT 
60 BEGIN 



Gaslnv.Package 



SELECT @tmpVolumeTotal=ISNULL((SELECT SUM(Gaslnv.PipelineActuals) FROM 
WHERE Gaslnv.GasMonth=@GasMonthx AND Gaslnv.DBCR=0 AND 



Gaslnv.PriceType=1 AND Gaslnv.KID=@yKlD 
65 AND Package.PKG=Gaslnv.PKG AND 

Package.KProductlD=@zKProductlD),0) 

END 

IF @yNetbackTierLevel='COMPANY* 
BEGIN 
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SELECT @tmpVolumeTotal=ISNULL((SELECT SUM(Gaslnv.PipelineActuals) FROM 

Gaslnv, Package 

WHERE Gaslnv.GasMonth=@GasMonthx AND Gaslnv.DBCR=0 AND 

Gaslnv.PriceType=1 AND Gaslnv.CID=@yCID 
5 AND Package.PKG=Gaslnv.PKG AND 

Package.KProductlD=@zKProductlD) t O) 

END 

END 

IF (@tmpVolumeTotal=0) OR (@tmpDayslnPeriod<1) 
10 BEGIN 

SELECT @yAveragePerDay=0 

END 

ELSE 

BEGIN 

1 5 EXECUTE uspJSetProductVolumeRound @PIDx,@zRound OUTPUT 

SELECT @yAveragePerDay=ROUND(@tmpVolumeTotal/@tmpDayslnPeriod,@zRound) 

END 

r x ^ auaauux ^ iiix ^ 

20 * Determine which effective date of rules 

* should be used. This will be the max 

* effective date where the effective date 

* is either in or prior to the end of the 

* current gas month. Only the set of rules 
25 * associated with the most recent effective 

* date will be used. If a date cannot be 

* found then this function will return 

* a zero percentage (ie. one isn't on 

* the system that precedes the gas 
30 * month). 

7 

SELECT @tmpMaxEffective=(SELECT MAX(effective) FROM knetback WHERE KID=(SELECT KID FROM package WHERE PKG=@PIDx) 
AND (effective<=@tmpEndDate) AND NetBackType=@TypeNetbackx) 

35 IF @tmpMaxEffective IS NULL 

BEGIN 

SELECT ©tmpMaxEffective^OI-OI-IQOO' 

END 

40 r i* 

* If method 0 (all or nothing) then go 

* and get the single tier percentage. 

* The tier record will loop through and 

* take the first tier record where the 
45 * volume is greater than or equal then 

* the average volume per day. 

* This is the all or nothing netback 

* pricing tier logic. 

50 7 

IF @yNetbackMethod=0 
BEGIN 

SELECT @yDaiiyTotal=@yAveragePerDay 

END 

55 ELSE 

BEGIN 

SELECT @yDaiiyTotal=0 

END 

r 



60 



* Initialize any fields that may be 

* needed during the loop process. 



7 

65 SELECT @tmpAccumulatingTotal=@yAveragePerDay 

SELECT @tmpPrevBand=0 
SELECT @tmpAccumulatingPrice=0 



70 * Now loop through all of the netback 
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* price records attached to the contract 



DECLARE NetbackCursor CURSOR LOCAL FORWARD.ONLY STATIC FOR 
SELECT 

effective, 
maxvollevel, 
netprice 
FROM 

kNetBack 

WHERE 

(KID=(SELECT KID FROM Package WHERE PKG=@PIDx)) AND 
(effective=@tmpMaxEffective) AND 
(maxvollevel>=@yDailyTotal) AND 
(NetbackType=@TypeNetbackx) 

ORDER BY 

maxvollevel asc 

OPEN NetbackCursor 

FETCH NEXT FROM NetbackCursor INTO @yEffective ( @ymaxvolIevel,@ynetprice 
WHILE @@FETCH_STATUS = 0 
BEGIN 

IF @yNetbackMethod=0 
BEGIN 

IF @yNetbackPercentage=0 
BEGIN 

SELECT @yNetbackPercentage=ROUND(@ynetprice,4) 

END 

END 

r ijl ijla jla 

* If method 1 (accumulating) then go 

* through and weight each tier to derive 

* a percentage. We know the total volume 

* for the month each tier will provide us 

* with the weighting information we need. 



*/ 

IF @yNetbackMethod=1 
BEGIN 

IF @tmpAccumulatingTotal>0 
BEGIN 

SELECT @tmpCurrBand=(@ymaxvollevel-@tmpPrevBand) 
IF @tmpCurrBand<=@tmpAccumulatingTotal 
BEGIN 

SELECT @tmpBandTotal=@tmpCurrBand 
SELECT 

@tmpAccumulatingTotal=(@tmpAccumulatingTotal-@tmpCurrBand) 

END 

ELSE 

BEGIN 

SELECT @tmpBandTotal=@tmpAccumulatingTotal 
SELECT @tmpAccumulatingTotal=0 

END 

SELECT @tmpBandWeightPerc=@tmpBandTotal 

SELECT @tmpBandWeightPerc=@tmpBandWeightPerc/@yAveragePerDay 

SELECT 

@tmpA(xumulatingPrice=@tmpAccumulatingPric 

END 

SELECT @tmpPrevBand=@ymaxvo!!eve1 

END 

FETCH NEXT FROM NetbackCursor INTO ©yEffective.gymaxvollevel.Qynetprice 

END 

CLOSE NetbackCursor 
DEALLOCATE NetbackCursor 

r 

****** *************** *>**>*>**»**»*»* ***** 

* Get the last accumulating price here 

* and use this price... 
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7 

IF @yNetbackMethod=1 
BEGIN 

SELECT @yNetbackPercentage=@tmpAccumulatingPrice 

END 

r 



* At this point a calculated netback 

* percentage has been derived. Now 

* check to see if the calculated netback 

* percentage is less than the 'floor 1 

* amount setup on the contract. If so, 

* then use the floor amount. 

7 

SELECT @ynetpricefloor=ISNULL((SELECT NetPriceFloor FROM K WHERE KID=(SELECT KID FROM Package WHERE PKG=@PIDx)),0) 
IF @ynetpricefloor<>0 
BEGIN 

IF @ynetpricefloor>@yNetbackPercentage 
BEGIN 

SELECT @yNetbackPercentage=@ynetpricefloor 

END 

END 

END 



GO 

SET QUOTED IDENTIFIER OFF SET ANSI.NULLS ON 
GO 

SET QUOTEDJDENTIFIER ON SET ANSI.NULLS ON 
GO 

CREATE PROCEDURE usp_fGetWASPIndicator( 

@PIDx INTEGER, 

©yWasplndicator VARCHAR(10) OUTPUT 
) 

AS 

BEGIN 

r 



Name: uspJGetWasplndicator 

Description: This function will return the WASP indicator for the package ID that 
was sent as an input parameter. The WASP indicator is based on the combination of 
deal classifications that have been established for this deal. The default indicator 
is 'None' (ie if classification information can't be found/etc). All combinations of 
deal classifications should be setup. 

Inputs: PIDx (package ID). 

Outputs: A 'Comon' or 'Dedicated' or 'None' indicator which specifies whether 
or not this package is considered 'WASP'able. 

History: 

05/12/1999 JAMIE Original Creation. 

08/03/1999 JAMIE Modification to use the deal classification indicators 
off of the package table versus the dealclass table. 
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7 

r 



* Declare all exceptions, cursors 

* and local variables that will be 

* utilized by this procedure. 

10 7 

DECLARE ©yDealContextID INTEGER 
DECLARE ©yDealTypelD INTEGER 
DECLARE @yDealVolumeVo!ID INTEGER 
DECLARE ©yDealPricePeriodID INTEGER 

1 5 DECLARE ©yDeallnterruptiblelD INTEGER 

r 

* Populate the various deal classification 

* identifiers based on the information 
20 * stored on the package table. 

7 

SELECT 

@yDealContextlD = PackageDBCR, 
25 ©yDealTypelD = DealTypedcID, 

O ©yDealVolumeVollD = VolumeVolatilitydcID, 

, fj @yDea!PricePeriodlD = PricePerioddcID, 

?S. @yDeallnterruptiblelD = InterruptibledcID 

FROM 

30 Package 
WHERE 

PKG=@PIDx 



wi 

a 

Li. 



35 * Now go and get the WASP indicator for 

* this particular deal. 



7 

SELECT @yWasplndicator=ISNULL((SELECT IncludelnWasp FROM rDealClassRules 

i M 40 WHERE 

hj DealContext=@yDealContextlD AND 

l2 DeaITypedclD=@yDealTypelD AND 

s _ VolumeVolatilitydclD=@yDealVolumeVollD AND 

U PricePerioddclD=@yDealPricePeriodlD AND 

y, 45 lnterruptibledclD=@yDeallnternjptiblelD);None') 
END 



GO 

50 SET QUOTEDJDENTIFIER OFF SET ANSI.NULLS ON 

GO 

SET QUOTEDJDENTIFIER OFF SETANSI.NULLS ON 
GO 

55 

CREATE PROCEDURE usp fGetWaspType( 

@PIDx INTEGER, 

@yWaspType VARCHAR(12) OUTPUT 
) 

60 AS 

BEGIN 

r 



Name: uspJGetWaspType 

65 

Description: This function will return the WASP type field to use for the 
specific package (deal) that is being looked at. This type is based on the 
product id setup for the deal. 

70 
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Inputs: 

PIDx (package ID). 
Outputs: 

yWaspType - 'OIL'/LIQUIDS', OR 'GAS'. 
History: 

12/03/2000 JAMIE Original Creation. 



7 

r 

* Declare all exceptions, cursors 

* and local variables that will be 

* utilized by this procedure. 

7 

DECLARE ©yDealProduct VARCHAR(50) 
DECLARE ©yDealProductID INTEGER 

r 

* Initialize the return value to be GAS 
7 

SELECT @yWaspType='GAS' 

r 

* Get the contrat ID off the deal 

* (package) table. 



7 

SELECT ©yDealProductlD = ISNULL((SELECT KProductID FROM package where PKG=@PIDx) t 0) 

r 



* If a contract ID was found then 

* based on the value then convert 
*the netback type. 



7 

IF @yDealProductlD <> 0 
BEGIN 

SELECT ©yDealProduct = ISNULL((SELECT shortdescription FROM SEProcesstngCodes WHERE processingcodeid 
@yDealProductlD);Gas') 

IF @yDealProduct = 'Gas' 
BEGIN 

SELECT @yWaspType= ( GAS' 

END 

IF@yDealProduct = 'OiP 
BEGIN 

SELECT @yWaspType- OIL' 

END 

IF @yDealProduct = liquids' 
BEGIN 

SELECT @yWaspType='LIQUlDS' 

END 

END 

END 



GO 

SET QUOTEDJDENTIFIER OFF SET ANSI.NULLS ON 
GO 
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SET QUOTEDJDENTIFIER ON SET ANSI.NULLS ON 
GO 



CREATE PROCEDURE usp_flsLastDay( 

@DT DATETIME 
) 

AS 

BEGIN 

DECLARE @LDx DATETIME 

DECLARE @a INTEGER 

EXECUTE usp.fLastDay @DT,@LDx OUTPUT 

IF @LDx=@DT 

BEGIN 

SELECT @a=1 

END 

ELSE 

BEGIN 

SELECT @a=0 

END 

RETURN(@a) 
END 



GO 

SET QUOTEDJDENTIFIER OFF SET ANSI NULLS ON 
GO 

SET QUOTEDJDENTIFIER ON SET ANSI.NULLS ON 
GO 

CREATE PROCEDURE usp_flastday( 

©lastdate DATETIME, 
@ldx DATETIME OUTPUT 
) 

AS 

BEGIN 

r 



* Initially, just set the return value to be 

* equal to the date coming in. 

7 

SELECT @ldx=@lastdate 

L* ******* H^XXl 

* Now, loop thru adding 1 day to the date 

* while the month is still equal. 



*/ 

WHILE MONTH(@ldx)=MONTH(@lastdate) 
BEGIN 

SELECT @ldx=DATEADD(DAY, 1 ,@ldx) 

END 

r 



* Since the loop would have finished with 

* the date being 1 day greater than the 

* last day of the month, then back it off 

* one day here to get the true end of 

* month value... 

7 

SELECT @ldx=DATEADD(DAY,-1 ,@ldx); 
END 



GO 

SET QUOTEDJDENTIFIER OFF SET ANSI.NULLS ON 
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GO 



SET QUOTED IDENTIFIER ON SET ANSLNULLS ON 
GO 

CREATE PROCEDURE usp_GasDayToGasMonth( 

©GasDayX DATETIME, 
©GasMonthX DATETIME OUTPUT 

) 

AS 

BEGIN 

r 



* Initially, just set the return value to be 

* equal to the date coming in. 



7 

SELECT @GasMonthX=@GasDayX 
{* 

* Now, loop thru subtracting 1 day to the 

* date while the month is still equal, 

7 

WHILE MONTH(@GasMonthX)=MONTH(@GasDayX) 
BEGIN 

SELECT @GasMonthX=DATEADD(DAY,-1 ,@GasMonthX) 

END 

r 

* Since the loop would have finished with 

* the date being 1 day less than the 

* first day of the month, then bump it up 

* one day here to get the true beginning of 

* month value... 



7 

SELECT @GasMonthX=DATEADD(DAY,1 ,@GasMonthX) 
END 



GO 

SET QUOTED IDENTIFIER OFF SET ANSLNULLS ON 
GO 

SET QUOTEDJDENTIFIER ON SET ANSLNULLS ON 
GO 

CREATE PROCEDURE usp_GetProductVolumeRound( 

@PKGx INTEGER, 
©RoundNumber INTEGER OUTPUT 
) 

AS 

r 



Name: usp.GetProductRound 

Description; Get the value used to round volumes to based on the information 
in the processing codes table (typelimit field). 

Inputs: 

RoundNumber - Number of digits to round calculations too. 

Outputs: 

None 

History: 
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11/23/2000 JAMIE Original creation. 



V 

BEGIN 

DECLARE ©zRoundNumber INTEGER 

SELECT ©zRoundNumber = ISNULL((SELECT SP.TypeLimit FROM SEProcessingCodes AS SP, Package WHERE SP.ProcessingCodelD 
Package.KProductID AND Package.PKG=@PKGx),0); 
SELECT ©RoundNumber = ©zRoundNumber 
END 



GO 

SET QUOTEDJDENTIFIER OFF SET ANSI.NULLS ON 
GO 

SET QUOTEDJDENTIFIER OFF SET ANSI.NULLS ON 
GO 

CREATE PROCEDURE uspJJnePrice( 

©nETID INTEGER, 
©nNomOrAct INTEGER 
) 

AS 

BEGIN 

r 



Name: uspJJnePrice 

Description: This procedure will calculate the line price for a specific Engine 
record. The input parameter nETID represents a unique key to a specific Engine 
record. In addition, the nNomOrAct parameter specifies whether or not to post the 
price line information to the nomination area or the actual area of the engine 
record. The volgroup field on the engine record contains the unique package (deal) 
id. This is used in the link to get the actual price components for the package. 

Inputs: 

nETID = Engine Key 

nNomOrAct = (0=Nomination,1=Actualization) 
Outputs: 

Either an updated PriceOrRateNom or PriceOrRateAct field on the Engine record. 

The precise field updated depends on the input parameter sent to this process (nNomOrAct). 

History: 

xx/xx/xx (?) CHIP Original Creation. 

04/29/99 JAMIE Modified for WASP 2.10 Release. Structure changes 

made to the Engine and EngineJ/laster tables. In 

addition, all documentation added. This particular 

portion of the system required extensive changes 

due to the need to store a nom and actual number 

and because all price components are now stored 

off the Engine.MasterPrice table (STID's 8 and 9). 

06/22/2000 JAMIE Modified to pull in the entity, product and service 
in order to get the correct price off the wasp table (values are passed 
to the wasp routine). 

1 1/10/2000 JAMIE Converted to Transact-SQL 



r 



-37- 



* Declare all exceptions, cursors 

* and local variables that will be 

* utilized by this procedure. 



DECLARE @xEngine_Effective DATETIME 

DECLARE ©xETID INTEGER 

DECLARE ©xSequenceNo INTEGER 
1 0 DECLARE ©xPriceTag VARCHAR(20) 

DECLARE ©xOperandVariable VARCHAR(1) 

DECLARE @xPriceVariable VARCHAR(15) 

DECLARE ©xPriceEntryType VARCHAR(12) 

DECLARE ©xEffective DATETIME 
1 5 DECLARE @xTID INTEGER 

DECLARE ©xEntityCID VARCHAR(12) 

DECLARE ©xKProductID INTEGER 

DECLARE ©xKServicelD INTEGER 

DECLARE ©yPrice DECIMAL(19,6) 
20 DECLARE ©yPricelnterimValue DECIMAL(1 9,6) 

DECLARE ©yMonthDate DATETIME 

DECLARE ©zTemp DECIMAL(19,6) 

_ DECLARE Engine_MasterPriceAil CURSOR LOCAL FORWARD.ONLY STATIC FOR 

Q 25 SELECT DISTINCT 

Ug emp.ETID, 
sfi- emp.SequenceNo, 

emp.PriceTag, 
emp.OperandVariable, 

yl 30 emp.PriceVariable, 

pc.PriceEntryType, 

^ em.Effective, 
H= e.TID, 
jLs. k.entitycid, 

35 package.KProductlD, 
3 package.KServicelD 
M* FROM 



60 



65 



engine_masterprice AS emp, 
engine AS e, 



W 40 engine_master AS em, 

pricecomponents AS pc, 



45 WHERE 



gasmv, 
k, 

package 



(e.ETID=@nETID) AND 
(em.ETID=e.EM_ETID) AND 
(emp.ETID=em.ETID) AND 
(gasinv.tid=e.tid) AND 

50 (k.kid=gasinv.kid) AND 

(package. pkg=gasinv.pkg) AND 
(pc.PriceTag=emp.PriceTag) AND 
(emp.NomOrActual=@nNomOrAct) 

ORDER BY 

55 emp.ETID, 

emp.SequenceNo 



' Initialize all fields here.. 
7 

SELECT @yPrice=0 

SELECT @yPricelnterimValue=0 

r 



* Open the cursor to get the pricing 

* information and loop through all of 

* the price component records. The end 

* result price will ultimately be 
70 * updated on the engine record. 
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10 



m 

3 - i 



V 

OPEN EngineJvlasterPriceAII 

FETCH NEXT FROM Engine_MasterPriceAII INTO 

^ETID.^SequenceNo^PriceTag.^OperandVariable.gxPriceVariable.QxPriceEntfyType, 

@xEffective,@xTID,@xEntityCID,@xKProductlD ( @xKServicelD 

WHILE @@FETCH_STATUS = 0 
BEGIN 

r 



* Derive the gas month based on the 

* effective from the engine 

* record. 

15 7 

SELECT @xEngine_Effective=(SELECT effective FROM engine WHERE ETID=@nETID) 
EXECUTE usp_GasDayToGasMonth @xEngine_Effective p @yMonthDate OUTPUT 

f ^ lllllllk 

20 * Convert the price variable portion to a 

* number. If an index then get the index 

* amounts. The default price for any 

* component not in this case statement is 
^ * zero ( ie W AS P, UNKNOWN, etc.). 

2 *> 

SELECT ©yPricelnterimValue = 0 
^ IF @xPriceEntryType= , Numeric' 

*U BEGIN 

m 30 SELECT @yPricelnterimValue=CAST(@xPriceVariable AS DECIMAL(19,6)) 

1-4 END 

^ IF @xPriceEntryType='Monthly IDX* 

M= BEGIN 

= = EXECUTE usp_fGetlndex@yMonthDate,@yMonthDate l ^PriceVariable,@yPricelnterimValue 

- 35 OUTPUT 

s END 
La IF @xPriceEntryType='Daily IDX' 

BEGIN 

EXECUTE uspJGetlndex 
40 @yMonthDate,@xEngine Effective P @xPriceVariable p @yPricelnterimValue OUTPUT 

END 

IF ©xPriceEntryType- Basket IDX' 
BEGIN 

EXECUTE uspJGetlndexBasket 
45 ©yMonthDate.tgxEngine.Effective.^PriceVariable.gyPricelnterim Value OUTPUT 

END 

IF @xPriceEntryType-Wasp' 
BEGIN 

EXECUTE uspJGetCalclndex 

50 @xTID,@nNomOrAct@xEntty^^ 

END 

IF ©yPricelnterimValue IS NULL 
BEGIN 

SELECT ©yPricelnterimValue = 0 

55 END 

r 



* At this point the yPricelnterim Value 

* contains the individual price component 
60 * amount. Now, depending on the operator, 

* apply this to the current total 

* (yPrice). The end result is yPrice 

* being updated with this component amount. 

65 V 

IF @xOperandVariable- +' 
BEGIN 

SELECT @yPrice=@yPrice^yPricelnterimValue 

END 

70 IF @xOperandVariable- 
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BEGIN 

SELECT @yPrice=@yPrice-@yPricelnterimValue 

END 

IF ©xOperandVariable- ** 
BEGIN 

SELECT @yPrice=@yPrice*@yPricelnterimValue 

END 

IF @xOperandVariable=T 
BEGIN 

IF (@yPrice<>0) AND (@yPricelnterimValue<>0) 
BEGIN 

SELECT @yPrice=@yPrice/@yPricelnterimValue 

END 

END 

FETCH NEXT FROM Engine JtesterPriceAII INTO 
@xETID,(^SequenceNo,(^PrireTag^ 

@xEffective,@xTID ( @xEntityCID,@xKProductlD,@xKServicelD 
END 

CLOSE Engine_MasterPriceAII 
DEALLOCATE Engine_MasterPriceAII 

r 



* Finally, take the results of the price 

* components and update the engine record 
*with the price. 

* If nom calculation then update then 

* nom price. If actual calculation then 

* update the actualized price. 



*/ 

IF @nNomOrAct=0 
BEGIN 

UPDATE 

Engine 
SET 

PriceOrRateNom=@yPrice 

WHERE 

ETID=@nETID 

END 

IF @nNomOrAct=1 
BEGIN 

UPDATE 

Engine 
SET 

PriceOrRateAct=@yPrice 

WHERE 

ETID=@nETID 

END 

END 



GO 

SET QUOTED IDENTIFIER OFF SET ANSI.NULLS ON 
GO 

SET QUOTED IDENTIFIER OFF SET ANSI.NULLS ON 
GO 

CREATE PROCEDURE usp_message( 

@messagex VARCHAR(255) 
) 

AS 

r 



Name: usp.message 
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Description: This routine will dictate where and how messages from the system 
will (or will not) be posted. These are transitory messages generated by the 
system (like during a calculation). 

Inputs: 

messagex - Text message to write 

Outputs: 

None 



History: 

11/07/2000 JAMIE Original creation. 



*/ 

BEGIN 

DECLARE ©tmpMessage VARCHAR(254) 

r 

INSERT INTO ApplicationMessages (ApplicationMessageText) VALUES (©messagex) 

PRINT ©messagex 
7 

SELECT ©tmpMessage = ©messagex 
END 



GO 

SET QUOTEDJDENTIFIER OFF SET ANSI.NULLS ON 
GO 

SET QUOTED IDENTIFIER OFF SET ANSI.NULLS ON 
GO 

CREATE PROCEDURE usp_PSPrice( 

©PIDx INTEGER, 
©WhichPricex INTEGER, 
©GasMonthx DATETIME, 
©DBCRx INTEGER 
) 

AS 

BEGIN 

r 



Name: usp_PSPrice 

Description: Price all of the gas inventory items. 
History: 

xx/xx/xx (?) CHIP Original Creation. 
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05/03/99 JAMIE Modified for WASP 2.10 Release. Structure changes 
made to the Engine and Engine_Master tables. In 

addition, all documentation added. In addition modifications were made to drive the 
pricing off package identifier versus Gas Inventory Transaction Identifier (TID). Since 
all pricing is done at a package level. 

Only those entries within the gas inventory with pricetype=1 
will be processed by this procedure. These entries represent 
only the purchase and sale items AND SHOULD HAVE Engine.Master 
records associated with them. 

07/12/2000 JAMIE Modified to check for the actualizedflag on the 
gasinv record. If the flag is set to a T then set the price accordingly. If 
the flag is set to something other than a T (ie.. 'N' or null) then the 
price will automatically get a zero. The price or rate number for actuals 
will still calculate AND it is possible that some meters within a deal will 
calculate (if the flag is set) while other meters on the same deal will not 
(if the flag is not set). The engine record is where all calculated results 
are stored and will contain zeros for the entries that have not been 
setup to be actualized. 



*/ 
/* 



* Declare all variables and cursors 

* that are needed by this process. 



*/ 

DECLARE ©tmpEndDate DATETIME 
DECLARE ©tmpNextEffectiveDate DATETIME 
DECLARE ©tmpNumberDays INTEGER 
DECLARE @tmpVolumelnPeriod DECIMAL(19,2) 
DECLARE ©tmpDateToUse DATETIME 
DECLARE @yTID INTEGER 
DECLARE ©yActualizedFlag VARCHAR(1) 
DECLARE @ySTID INTEGER 
DECLARE ©yEffective DATETIME 
DECLARE @yETID INTEGER 

DECLARE @zRound INTEGER 

DECLARE GaslnventoryCursor CURSOR LOCAL STATIC FORWARD.ONLY FOR 
SELECT 

DISTINCT 
TID, 

ActualizedFlag 
FROM 

Gasinv 

WHERE 

(PKG=@PlDx)AND 
(PriceType=1)AND 
(DBCR=@DBCRx) 

r x ^ UiXUXUiU1I11JLXXX 

* At this point the calculation needs to 

* happen. Iterate through each of the 

* inventory items attached to this particular 

* package... Only STID's of 8 or 9 are 

* priced here... (STID=8 is DBCR=0 is a 

* purchase),(STID=9 is DBCR=1 is a sale). 

* Within each inventory item go through 

* each effective date/STID and use the 

* pricing rules to determine whether the 

* pricing accumulates or is all or 

* nothing. 



*/ 
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EXECUTE usp.GetProductVolumeRound @PIDx,@zRound OUTPUT 
OPEN GaslnventoryCursor 

FETCH NEXT FROM GaslnventoiyCursor INTO @yTID,@yActualizedFlag 
WHILE @@FETCH_STATUS = 0 
BEGIN 

DECLARE EngineCursor CURSOR LOCAL STATIC FORWARD.ONLY FOR 
SELECT 

DISTINCT 

e.ETID, 

e. Effective, 

e.STID, 

e.TID 

FROM 

Engine AS e, 
Engine_MasterAS em 

WHERE 

(em.ETlD=e.EM_ETID) AND 
(em.PID=e.VolGroup) AND 
(e.TID=@yTID) 

ORDER BY 

e.ETID 

OPEN EngineCursor 

FETCH NEXT FROM EngineCursor INTO @yETID,@yEffective,@ySTID ( @yTID 
WHILE @@FETCH_STATUS = 0 
BEGIN 

r 



* Calculate and update the engine with the 

* the actual price from the engine_master 

* via call to the following function. 



7 

EXECUTE uspJJnePrice @yETID,@WhichPricex 

r 

* Determine the volume total to be applied 

* to this price line here. This represents 

* the sum of the volume between the 

* effective date and the end of the 

* month OR the next price effective 

* date for this item. The value of 

* tmpNumberDays contains the number of 

* days to apply the price and volumes 

* toward within the calculation. 



7 

EXECUTE uspJLastDay @GasMonthx p @tmpEndDate OUTPUT 
SELECT @tmpNextEffectiveDate=(SELECT MlN(effective)-1 FROM engine AS e WHERE 
(e.TID=@yTlD) AND (e.STID=@ySTID) AND (e.Effective>@yEffective)) 

IF ©tmpNextEffectiveDate IS NULL 
BEGIN 

SELECT @tmpNextEffectiveDate=@tmpEndDate 

END 

IF @tmpNextEffectiveDate<@tmpEndDate 
BEGIN 

END 

ELSE 

BEGIN 
END 

SELECT @tmpNumberDays=DATEDIFF(day,@yEffective,@tmpDateToUse) + 1 
IF @WhichPricex=0 
BEGIN 

SELECT @tmpVolumelnPeriod=lSNULL((SELECT SUM(Nom) FROM 

GaslnvD WHERE (GaslnvD.TID=@yTID) 

AND 

(GaslnvD.GasDay BETWEEN @yEffective AND @tmpDateToUse)),0) 

END 

IF @WhichPricex=1 



SELECT @tmpDateToUse=@tmpNextEffectiveDate 
SELECT @tmpDateToUse=@tmpEndDate 
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BEGIN 

IF @yActualizedFlag=T 
BEGIN 

SELECT @tmpVolumelnPeriod=lSNULL((SELECT 

SUM(PipelineActuals) FROM GaslnvD WHERE (GaslnvD.TID=@yTID) 

AND (GaslnvD.GasDay BETWEEN @y Effective AND @tmpDateToUse)),0) 

END 

ELSE 

BEGIN 

SELECT @tmpVolumelnPeriod=0 
END 

END 

r ^ 

* Update the actual engine volumes and 

* amounts here... 

*/ 

IF @WhichPricex=0 
BEGIN 

UPDATE 

Engine 
SET 

Volume=ROUND(@tmpVolumelnPeriod,@zRound), 

Amount=ROUND((@tmpVolumelnPeriod*Engine.PriceOrRateNom),2) 

WHERE 

END 

IF @WhichPricex=1 
BEGIN 

UPDATE 

Engine 
SET 

VolumeAct=ROUND(@tmpVolumelnPeriod,@zRound) p 

AmountAct=ROUND((@tmpVolumelnPeriod*Engine.PriceOrRateAct),2) 

WHERE 

ETID=@yETID 

END 

FETCH NEXT FROM EngineCursor INTO @yETID,@yEffective,@ySTID,@yTID 

END 

CLOSE EngineCursor 
DEALLOCATE EngineCursor 

FETCH NEXT FROM GaslnventoryCursor INTO @yT!D,@yActualizedFlag 

END 

CLOSE GaslnventoryCursor 
DEALLOCATE GaslnventoryCursor 
END 



ETID=@yETID 



GO 

SET QUOTEDJDENTIFIER OFF SET ANSI NULLS ON 
GO 

SET QUOTED IDENTIFIER OFF SET ANSI NULLS ON 
GO 

CREATE PROCEDURE usp_PSPriceAII( 

©GasMonthx DATETIME, 
©DebitCreditx INTEGER, 
©WhichPricex INTEGER, 
@PKGx INTEGER, 
@EntityCIDxVARCHAR(12), 
©IncludelnWASPx VARCHAR(10) 
) 

AS 
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BEGIN 

r 

Name: usp_PSPriceAll 



Description: 

Loop thruough all packages (deals) involved within a given month (purchase 
or sale) and invoke the price procedures. 

Inputs: 

GasMonthx (Gas Month to price), 
DebitCreditx (0=Debit (Purchases) - 1=Credit (Sales)), 
WhichPricex ^Nominations, ^Actualizations 
PKGx (0=all otherwise specific package ID) 
EntityCIDx (owning company entity id) 

IncludelnWASPx (" for all, otherwise check for 'Common7Dedicated\ or 'None') 



History: 

05/13/99 JAMIE This entire process was rewritten with V2.10 of 
the Gas Control System. Package driven now 
instead of individual inventory item driven. 



07/22/99 JAMIE Include 3rd party deals within the 
calcualtion process. They WILL NOT BE included within the WASP calculations 
and will be treated the same as "Dedicated" (sanctioned sales) deals. This 
will ensure they are not affecting any other pricing component 

05/24/2000 JAMIE Modified to include the changes to calculate based on company 
entity ID (passed to this calculation). This ensures that WASP calculations/etc 
are all within their respective companies... The deal cursor (PackageCursor) 
will now only select those items where the entity ID for the contract on the deal 
matches the one passed to this routine. 

07/26/2000 JAMIE Modified to include the IncludelnWaspx parameter to 
this particular procedure. This will allow certain types of deals to 
be priced independently of other types (ie.. do 3rd party first in order 
to divie the proceeds either to a pool OR to another deal). 



r 

* Declare all variables and cursors 

* that are needed by this process. 

*/ 

DECLARE ©zTypeText VARCHAR(10) 
DECLARE ©zMessage VARCHAR(255) 

DECLARE @yPKG INTEGER 

DECLARE ©ylncludelnWasp VARCHAR(10) 

DECLARE PackageCursor CURSOR LOCAL STATIC FORWARD.ONLY FOR 
SELECT 

DISTINCT 

Gaslnv.PKG 

FROM 

Gaslnv, 

Package, 

K 



WHERE 



Package.PKG=Gaslnv.PKG AND 
K.KID=Package.KID AND 
K.EntityCID=@EntityCIDx AND 
Gaslnv.GasMonth=@GasMonthx AND 
Gaslnv.DBCR=@DebitCreditx AND 
Gaslnv.PriceType=1 
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ORDER BY 

Gaslnv.PKG 



5 * Initialize any fields required. 

*/ 

IF @DebitCreditx=0 
BEGIN 

1 0 SELECT ©zTypeText- Purchase' 

END 

IF @DebitCreditx=1 
BEGIN 

SELECT @zTypeText='Sale' 

15 END 

f* 

* Loop through each package 

* involved in this calculation. As each 
20 * deal is fetched get its WASP indicator 

* information in order to determine if 

* it can be involved in this process. 

*/ 

25 OPEN PackageCursor 

FETCH NEXT FROM PackageCursor INTO @yPKG 
WHILE @@FETCH_STATUS = 0 
BEGIN 

BEGIN TRANSACTION 

30 EXECUTE uspJGetWASPIndicator @yPKG,@ylncludelnWasp OUTPUT 

IF (@PKGx=0) OR ((@PKGx<>0) AND (@PKGx=@yPKG)) 
BEGIN 

IF (@lncludelnWaspx=") OR (@lncludelnWaspx=@ylncludelnWasp) 
BEGIN 

35 SELECT ©zMessage = 'PSPriceAII Running for Entity 

'+@EntityCIDx+' and type l +@zTypeText+\ Package:'*' '^ONVERT(VARCHAR(10),@yPKG)+\...' 

EXECUTE usp_message @zMessage 
r 

40 * Reset the financial override dollar 

* amount to zeros at the beginning of the 

* calculate for the deal... 



45 



50 



7 

IF @WhichPricex=0 
BEGIN 
UPDATE 



package 
SET 



FinancialNomAmount=0 



55 



60 



END 

IF @WhichPricex=1 
BEGIN 
UPDATE 



WHERE 



package 
SET 



PKG=@yPKG 



65 



FinancialActAmount-0 



END 



WHERE 



PKG=@yPKG 



70 



* Create any system generated pricing 

* components for this package... These 
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* pricing components are tightly related 

* to the Engine_Master. This is needed 

* to be done prior to populating the 

* Engine with pricing information. 



EXECUTE usp.PSPriceComponentsCheck 

@yPKG,@WhichPricex ( @GasMonthx,@DebitCreditx 

r 



* Now create all engine items for all 

* Engine_Master records. This is where 

* the engine will be populated with entries 

* based on information stored in the 

* Engine Jvlaster. Included is the daily 

* index price 'proliferation* routine. 

V 

EXECUTE usp.PSPricePopulateEngine 

@yPKG,@WhichPricex ( @GasMonthx,@DebitCreditx 

r 



* Finally, now go and price the actual 

* engine entries that were created in the 

* previous step... 



*/ 

EXECUTE usp_PSPrice 

@yPKG,@WhichPricex,@GasMonthx 1 @DebitCreditx 

END 

END 

COMMIT WORK 

FETCH NEXT FROM PackageCursor INTO @yPKG 

END 

CLOSE PackageCursor 
DEALLOCATE PackageCursor 
END 



GO 

SET QUOTED IDENTIFIER OFF SET ANSI.NULLS ON 
GO 

SET QUOTED IDENTIFIER OFF SET ANSLNULLS ON 
GO 

CREATE PROCEDURE usp_PSPriceAnyNewlnvoicesNeeded( 

@GasMonthx DATETIME, 

@EntityCIDxVARCHAR(12) 

) 

AS 

BEGIN 
/* 



Name: usp_PSPriceAnyNewlnvoicesNeeded 
Description: 

This routine gets executed once a gas month has been put 
in an 'Invoiced' status. It will automatically go out and assign and invoice 
number where one previously did not exist (could use the same invoice 
number as an existing). 

Inputs: 
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GasMonthx - Gas month being calculated 
EntityCIDx - owning company 

History: 

12/15/1999 JAMIE Original creation 

12/21/1999 JAMIE Modify to put the monthly aphabetic code as the first 
field of the invoice number to eliminate OGSYS clipping of a leading zero. 

05/24/2000 JAMIE Modified to only create the invoices within the given owning 
company. The invoice numbers will need to be unique within the entire system. 



7 

r 

* Declare all variables and cursors 

* that are needed by this process. 



7 

DECLARE @yTID INTEGER 
DECLARE @yCID VARCHAR(12) 
DECLARE @yPipe VARCHAR(12) 
DECLARE @zAcctg Identifier VARCHAR(1 2) 
DECLARE @zYear INTEGER 
DECLARE ©zYearString VARCHAR(1) 
DECLARE ©zMonth INTEGER 
DECLARE ©zMonthString VARCHAR(1) 
DECLARE @zNumToUse INTEGER 
DECLARE ©zNumToUseLength INTEGER 
DECLARE ©zNumToUseString VARCHAR(3) 
DECLARE @zNumToUseZeros VARCHAR(3) 
DECLARE ©zMaxAcctgldentifier VARCHAR(12) 
DECLARE ©zWorkString VARCHAR(12) 

DECLARE GaslnvCursor CURSOR LOCAL STATIC FORWARD.ONLY FOR 
SELECT 

Gaslnv.TID, 
Gaslnv.CID, 
Gaslnv.PipeField 
FROM 

Gaslnv, 

Package, 

K 

WHERE 

Gaslnv.GasMonth=@GasMonthx AND 
Gaslnv.PriceType=1 AND 
Gasinv.DBCR=1 AND 

(Acctgldentifier IS NULL OR Acctg Identifier") AND 
Package.PKG=Gaslnv.PKG AND 
K.KID=Package.KlD AND 
K.EntityCID=@EntityCIDx 

ORDER BY 

Gaslnv.CID, 
Gaslnv.PipeField 

r 



* Determine the prefix to use for the 

* creation of the invoice numbers. If more 

* than 10 years then these numbers begin 

* to be reused. 
* 

* This routine is CHEAP but it should 

* suffice. 

*/ 

SELECT @zYear=YEAR(@GasMonthx) 

SELECT @zYearString=RIGHT(CONVERT(VARCHAR(4),@zYear),1) 
SELECT @zMonth=MONTH(@GasMonthx) 
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15 
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50 



55 



60 



65 



70 



IF @zMonth=1 

BEGIN 

END 
IF @zMonth=2 

BEGIN 

END 
IF @zMonth=3 

BEGIN 

END 
IF @zMonth=4 

BEGIN 

END 
IF @zMonth=5 

BEGIN 

END 
IF @zMonth=6 

BEGIN 

END 
IF @zMonth=7 

BEGIN 

END 
IF @zMonth=8 

BEGIN 

END 
IF @zMonth=9 

BEGIN 

END 

IF@zMonth=10 

BEGIN 

END 

IF@zMonth=11 

BEGIN 

END 

IF @zMonth=12 

BEGIN 

END 



SELECT @zMonthString= , A' 
SELECT @zMonthString='B' 
SELECT @zMonthString='C' 
SELECT @zMonthString='D* 
SELECT @zMonthString= , E' 
SELECT @zMonthString='F 
SELECT @zMonthString='G' 
SELECT @zMonthString='H' 
SELECT @zMonthString=T 
SELECT @zMonthString='J' 
SELECT ©zMonthString^K' 
SELECT @zMonthString=l' 



r 

* Find the starting point to begin 

* assigning new invoices from just 

* in case some numbers need to be 

* assigned. 

*/ 

SELECT @zNumToUse=0 

SELECT @zMaxAcctgldentifier=(SELECT max(Acctg Identifier) FROM Gaslnv WHERE GasMonth=@GasMonthx AND DBCR=1 AND 
PriceType=1) 

IF LEN(@zMaxAcctgldentifier) = 6 
BEGIN 

SELECT @zWorkString^RIGHT(@zMaxAcctgldentifier,4) 

SELECT @zWorkString=LEFT(@zWorkString,3) 

SELECT @zNumToUse=CONVERT(INTEGER,@zWorkString) 

END 

r 

* Now go get the records that do not 

* yet have a invoice number assigned 

* to them (ie. execute the cursor). 



-49- 



7 

OPEN GaslnvCursor 

FETCH NEXT FROM GaslnvCursor INTO @yTlD,@yCID,@yPipe 
WHILE @@FETCH_STATUS = 0 
BEGIN 

r 



10 



* Now go and find one, if one exists. 



7 

SELECT @zAcctgldentifier=(SELECT DISTINCT(Acctg Identifier) FROM Gaslnv WHERE GasMonth=@GasMonthx AND 

DBCR=1 AND PriceType=1 AND CID=@yClD AND PipeField=@yPipe 

AND Acctgldentifier IS NOT NULL AND Acctgldentifiero") 

15 

IF @zAcctgldentifier IS NULL 
BEGIN 

r 

** itirii ** **** ** ** ********* ** ****** ♦* * ******* 

20 ' * For each of these combinations generate 

* and invoice number and update the Gaslnv 

* table... Make sure that the number 

* to use is padded with zeros in order 

„ * to create a complete invoice number. 

U 25 * REALLY CHE AP ZERO PADDING . 

*Q ****************** 

^ SELECT @zNumToUse=@zNumToUse+1 

03 SELECT @zNumToUseString=CONVERT(VARCHAR(3),@zNumToUse) 

[fj 30 SELECT @zNumToUseLength=LEN(@zNumToUseString) 

SELECT @zNumToUseZeros=" 
& IF @zNumToUseLength < 3 

BEGIN 

iy. IF @zNumToUseLength=2 

35 BEGIN 
■ s SELECT @zNumToUseZeros='0' 

J** END 
h. ; IF @zNumToUseLength=1 

BEGIN 

yj 40 SELECT @zNumToUseZeros= , 00' 

END 

« END; 
W SELECT 

M= @zAcx^gldentifier=@zMonthString^zYearString4@zNumToUseZeros-^@zNumToUseString+'N' 
45 r ^ 

* Finally, post the invoice number that 

* was just created to the gas inventory 

* table. 



50 

7 

UPDATE 

Gaslnv 
SET 

55 Acctgldentifier=@zAcctg Identifier 

WHERE 

GasMonth=@GasMonthx AND 
DBCR=1 AND 
PriceType=1 AND 

60 CID=@yCIDAND 

PipeField=@yPipe AND 
TID=@yTID 

END 

FETCH NEXT FROM GaslnvCursor INTO @yTID,@yCID ( @yPipe 

65 END 

CLOSE GaslnvCursor 
DEALLOCATE GaslnvCursor 
END 

70 
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GO 

SET QUOTEDJDENTIFIER OFF SET ANSl.NULLS ON 
GO 

SET QUOTED IDENTIFIER OFF SET ANSl.NULLS ON 
GO 

CREATE PROCEDURE usp_PSPriceAssignlnvoiceNo( 

©GasMonthx DATETIME 
) 

AS 

BEGIN 

SET NOCOUNT ON 

r 



Name: usp_PSPriceAssignlnvoiceNo 

Description: This routine will clear out any existing invoice numbers on the gas 
inventory table AND generate/assign an invoice number and post to the gas 
inventory table. 

This particular routine is only looking at 'Sales' (DBCR=1) within the specified 
gas month (GasMonthx) that have a price type of '1' (ie.. not a transport inventory 
item). 

The format of the invoice number that gets generated will be as follows: 
Character 

1 Represents alph code for month (A=January, B=February, etc.). 

2 Represents the last digit of the year (1 999=9, 2000=0, etc.). 
3-5 Represents unqiue number assigned, 

6 Represents 'N' for Nominations. 

These invoice numbers are generated uniquely for all sales meters within a given pipe and 
company identifier. This procedure will assign the invoice number to both the 
nom and actual fields. Later (during actual calculations) the actual invoice number may 
or may not get updated based on the modifications made to the volumes or prices. 

Inputs: GasMonthx (Gas Month to calculate), 

History: 

10/27/1999 JAMIE Original creation 

1 1/19/1999 JAMIE Modified the number creation to post the final character as 
an 'N'. 

12/21/1999 JAMIE Modified the number creation process to put the monthly 
alphabetic code at the beginning of the invoice number instead of the 2nd 
character. 



*/ 

r 



* Declare all variables and cursors 

* that are needed by this process. 

V 

DECLARE @yCID VARCHAR(12) 
DECLARE @yPipe VARCHAR(12) 
DECLARE ©zAcctgldentifier VARCHAR(12) 
DECLARE @zYear INTEGER 
DECLARE ©zYearString VARCHAR(1) 
DECLARE ©zMonth INTEGER 
DECLARE ©zMonthString VARCHAR(1) 
DECLARE ©zNumToUse INTEGER 
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10 



DECLARE ©zNumToUseLength INTEGER 
DECLARE ©zNumToUseString VARCHAR(3) 
DECLARE ©zNumToUseZeros VARCHAR(3) 
r 

* Determine the prefix to use for the 

* creation of the invoice numbers. If more 

* than 10 years then these numbers begin 

* to be reused. 

* This routine is CHEAP but it should 

* suffice. 



n 



15 
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*/ 

SELECT @zYear=YEAR(@GasMonthx) 

SELECT @zYearString=RIGHT(CONVERT(VARCHAR(4) J @zYear),1) 
SELECT @zMonth=MONTH(@GasMonthx) 
F @zMonth=1 

BEGIN 

END 
F @zMonth=2 

BEGIN 

END 
F @zMonth=3 

BEGIN 

END 
F @zMonth=4 

BEGIN 

END 
F @zMonth=5 

BEGIN 

END 
F @zMonth=6 

BEGIN 

END 
F @zMonth=7 

BEGIN 

END 
F @zMonth=8 

BEGIN 

END 
F @zMonth=9 

BEGIN 

END 

F@zMonth=10 

BEGIN 

END 

F@zMonth=11 

BEGIN 

END 

F@zMonth=12 

BEGIN 

END 



SELECT @zMonthString='A' 



SELECT ©zMonthString^B' 



SELECT @zMonthString='C* 



SELECT ©zMonthString^D' 



SELECT ©zMonthString^E' 



SELECT @zMonthString='F 



SELECT @zMonthString='G' 



SELECT @zMonthString- hr 



SELECT @zMonthString- r 



SELECT @zMonthString=7 



SELECT ©zMonthString- K' 



SELECT @zMonthString='L' 



70 



* Clear out the invoice number that may 

* have preexisted for this particular 

* gas month (this number will always be 
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* empty UNLESS the gas month is opened 

* and closed more than once). 

V 

BEGIN TRANSACTION 
UPDATE 

Gaslnv 
SET 



10 WHERE 



15 COMMIT WORK 

r 



Acctgldentifier=NULL 

GasMonth=@GasMonthx AND 
DBCR=1 AND 
PriceType=1 AND 

(Acctgldentifier IS NOT NULL OR Acctgldentifiero") 



* Now build a cursor that contains all of 

* the unique combinations of company and 
20 * pipeline (ordered by company and pipeline). 

7 

SELECT @zNumToUse=0 

DECLARE GaslnvCursor CURSOR LOCAL STATIC FORWARD_ONLY FOR 
_ 25 SELECT 

O DISTINCT 

(Gaslnv.CID), 

r: (Gaslnv.PipeField) 
W FROM 

30 Gaslnv 
s === WHERE 

? £r Gaslnv.GasMonth=@GasMonthx AND 

Q Gaslnv.PriceType=1 AND 

jL-fe Gasinv.DBCR=1 
L 35 ORDER BY 

Gaslnv.CID, 

•s Gaslnv.PipeField 
OPEN GaslnvCursor 

^ , FETCH NEXT FROM GaslnvCursor INTO @yCID,@yPipe 

IU 40 WHILE @@FETCH_STATUS = 0 

hj BEGIN 

T T BEGIN TRANSACTION 

r 



45 * For each of these combinations generate 

* and invoice number and update the Gaslnv 

* table... Make sure that the number 

* to use is padded with zeros in order 

* to create a complete invoice number. 
50 * REALLY [ CH^PZERO PADDING. 

7 

SELECT @zNumToUse=@zNumToUse+1 

SELECT @zNumToUseString=CONVERT(VARCHAR(3),@zNumToUse) 
55 SELECT @zNumToUseLength=LEN(@zNumToUseString) 

SELECT @zNumToUseZeros=" 
IF ©zNumToUseLength < 3 
BEGIN 

IF @zNumToUseLength=2 
60 BEGIN 

SELECT ©zNumToUseZeros- 0' 

END 

IF @zNumToUseLength=1 
BEGIN 

65 SELECT @zNumToUseZeros= , 00' 

END 

END 

SELECT ©zAcctgldentifieRgzMonthString^zYearString^zNumToUseZeros-^zNumToUseString+'N' 

r 

70 
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* Finally, post the invoice number that 

* was just created to the gas inventory 

* table. 



V 

UPDATE 

Gaslnv 
SET 

Acctgldentifier=@zAcctgldentifier 

WHERE 

GasMonth=@GasMonthx AND 
DBCR=1 AND 
PriceType=1 AND 
CID=@yCIDAND 
PipeField=@yPipe 

COMMIT WORK 

FETCH NEXT FROM GaslnvCursor INTO @yCID,@yPipe 

END 

CLOSE GaslnvCursor 
DEALLOCATE GaslnvCursor 
END 



GO 

SET QUOTEDJDENTIFIER OFF SET ANSLNULLS ON 
GO 

SET QUOTEDJDENTIFIER OFF SET ANSLNULLS ON 
GO 

CREATE PROCEDURE usp.PSPriceAuto 
AS 

BEGIN 

r ^ Li iiiiiiiiii i 

Name: usp_PSPriceAuto 
Description: 

This procedure will be scheduled at automatically calculate the gas months 
in their respective stages. Noms get calculated for gas months in the 'Sales' stage. 
Pipeline actuals get calculated for gas months in the 'Invoiced' stage. All other gas 
months are ignored by this process. 

Inputs: 

None 

History: 

07/29/1999 JAMIE Original Creation. 

10/20/1999 JAMIE Modified to invoke the PSPriceCostAII routine which will 
calculate other costs for deals and post them to the engine table. 

03/22/2000 JAMIE Modified to invoke the single month calculation routine. This will 
ensure easier (non duplicated) maintenance on procedures to update price calculations. 



r 

* Declare all variables and cursors 

* that are needed by this process. 
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DECLARE @yGasMonth DATETIME 

r 



* First, calculate all of the nom 

* numbers (each gas month). 



*/ 

DECLARE GasMonthCursorl CURSOR LOCAL STATIC FORWARD.ONLY FOR 
SELECT 

GasMonth 
FROM 

rGasMonth 

WHERE 

CurrentStatus^Sales* AND 
(LockedUser IS NULL OR LockedUser=") 

ORDER BY 

GasMonth 

OPEN GasMonthCursorl 

FETCH NEXT FROM GasMonthCursorl INTO ©yGasMonth 
WHILE @@FETCH_STATUS = 0 
BEGIN 

EXECUTE usp.PSPriceAutoMonth @yGasMonth,0 
FETCH NEXT FROM GasMonthCursorl INTO ©yGasMonth 

END 

CLOSE GasMonthCursorl 
DEALLOCATE GasMonthCursorl 

r 



* Now calculate based on the pipeline 

* actuals each month. 



V 

DECLARE GasMonthCursor2 CURSOR LOCAL STATIC FORWARD_ONLY FOR 
SELECT 

GasMonth 
FROM 

rGasMonth 

WHERE 

CurrentStatus- Invoiced' AND 
(LockedUser IS NULL OR LockedUser= M ) 

ORDER BY 

GasMonth 

OPEN GasMonthCursor2 

FETCH NEXT FROM GasMonthCursor2 INTO @yGasMonth 
WHILE @@FETCH STATUS = 0 
BEGIN 

EXECUTE usp.PSPriceAutoMonth @yGasMonth,1 
FETCH NEXT FROM GasMonthCursor2 INTO ©yGasMonth 

END 

CLOSE GasMonthCursor2 
DEALLOCATE GasMonthCursor2 
END 



GO 

SET QUOTEDJDENTIFIER OFF SET ANSI_NULLS ON 
GO 

SET QUOTED IDENTIFIER OFF SET ANSI NULLS ON 
GO 

CREATE PROCEDURE usp_PSPriceAutoMonth( 

©GasMonthx DATETIME, 
©WhichVolumex INTEGER 
) 

AS 

BEGIN 

SET NOCOUNT ON 
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r 



Name: usp_PSPriceAutoMonth 

5 Description: 

This procedure will be execute all of the price calculation procedures 
required for a given month INCLUDING locking the month from other executions... This 
particualr procedure will be executed asynchronously by the system through the online 
1 0 screens. 

Inputs: 

GasMonthx (Gas month to calculate) 
1 5 Which Volumex (Price noms=0, Price actuals=1) 

History: 

08/31/1999 JAMIE Original Creation. 

20 

12/15/1999 JAMIE Modified to execute a new stored procedure once 
the gas month has been changed to the 'Accounting' status. This new 
procedure will mark and 'zap' the invoice numbers (amongst other things) 
on those gas inventory items were some sort of a price or volume adjustment 
25 was made. 

yp 03/22/2000 JAMIE Modified this process to handle all of the calculations for 

pi gas months, etc. Moved the 'Divie* process to this routine (was buried within 

« the transport cost module). 

;d 30 

if] 05/24/2000 JAMIE Modified to enable an outer cursor on company entity (CID). This will 

£3 allow for the partitioning of the calculations based on company ID (so we don't mix 

fT WASP Pool results/etc). 

M< 35 07/26/2000 JAMIE Modified to incorporate the changes to process calculations for certain 

types of deals prior to others (ie. 3rd party first so that profits can be distributed. 
; This change included passing a new parameter to the PSPriceAII function (on which 

H= pool ("for all)... 

~ 40 08/25/2000 JAMIE Modified to remove logic that invoked the older calculation 

routines. 

02/01/2001 JAMIE Modified to remove the transport section (commented out). 



45 



50 



*/ 

DECLARE @yCIDEntity VARCHAR(12) 
DECLARE @yGasMonth DATETIME 
DECLARE ©yCurrentStatus VARCHAR(20) 



DECLARE EntityCIDCursor CURSOR LOCAL STATIC FORWARD.ONLY FOR 
SELECT 

CID 
FROM 

55 company 

WHERE 

EntitylndicatopY 

ORDER BY 

CID 

60 r 



* Execute a cursor to calculate based on 

* entity. 

65 */ 

OPEN EntityCIDCursor 

FETCH NEXT FROM EntityCIDCursor INTO @yCIDEntity 
WHILE @@FETCH_STATUS = 0 
BEGIN 

70 r 
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* Now only calculate if the month 

* is not currently involved with a 

* calculation of some sort {month 

* needs to be unlocked). 
* 

* If the status was modified and the 

* current status in 'Invoiced' then 

* go and build all of the pipeline 

* actuals. 



*/ 

DECLARE GasMonthCursor CURSOR LOCAL STATIC FORWARD.ONLY FOR 
SELECT 

GasMonth, 

CurrentStatus 

FROM 

rGasMonth 

WHERE 

GasMonth=@GasMonthx AND 
(LockedUser IS NULL OR LockedUser=") 

OPEN GasMonthCursor 

FETCH NEXT FROM GasMonthCursor INTO @yGasMonth,@yCurrentStatus 
WHILE @@FETCH STATUS = 0 
BEGIN 

r 



* Indicate that the gas month is in 

* progress so that no one else tryes to 

* calculate at the same time. 



7 

UPDATE 

rGasMonth 
SET 



WHERE 



LockedUser='PSPriceAutoM', 
LockedDate=getdate() 

GasMonth=@GasMonthx 



* Calculate prices on all sales deals... 



7 

EXECUTE usp_PSPriceAII @GasMonthx,1, ©Which Volumex.O.QyCIDEntity," 
/* ^ ^ 

* Calculate 'Other Costs' associated to 

* all sales deals (required here in 

* order to post the other cost amounts 

* to WASP pools/etc... 

7 

EXECUTE usp_PSPriceCostAII @GasMonthx l @WhichVolumex l (8yCIDEntity,1," 

r 



* Now create the temporary WASPRouting 

* table entries for all products, services 

* and wasp types. The calculations will 

* not 'walk back' from sale to purchase 

* here (unless OLD routing month)... 

7 

EXECUTE usp.PSPriceWASPCalc @GasMonthx,@WhichVolumex,@yCIDEntity 
/* 1U i.»»i.>»i»nx 

* If new routing method then resolve based 
*on entity and IncludelnWasp pool. This 

* is done this way in order to potentially 

* distribute proceeds from 3rd party 
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* deals back to either a WASP pool meter 

* or to another deal... 

* 1 . Resolve and price 'None* pool. 

* 2. Divie out any proceeds. 

* 3. Resolve and price 'Dedicated' pool. 

* 4. Resolve and price 'Common' pool. 



*/ 

EXECUTE usp.PSPriceWASPCalcResolveDriver 
@GasMonthx,@WhichVolumex,@yCIDEntity P 'None' 

EXECUTE usp.PSPriceAII ©GasMonthx.O^WhichVolumex.O^yCIDEntity.'None' 
EXECUTE usp_PSPriceCostAII @GasMonthx,@WhichVolumex,@yCIDEntity,07None' 
EXECUTE usp_PSPriceWASPDivieOutProceedsN 

@GasMonthx,@WhichVolumex,@yCIDEntity 

EXECUTE usp.PSPriceWASPCalcResolveDriver 

@GasMonthx,@WhichVolumex,@yCIDEntity 1 l Dedicated' 

EXECUTE usp.PSPriceAII @GasMonthx,O t @WhichVolumex,0,@yCIDEntity;Dedicated' 
EXECUTE usp.PSPriceCostAII ©GasMonthx, ©Which Volumex.gyCIDEntity.O.'Dedicated' 
EXECUTE usp_PSPriceWASPCa!cResolveDriver 

gGasMonthx.gWhichVolumex.gyCIDEntity/Common' 

EXECUTE usp.PSPriceAII ©GasMonthx.O.gWhichVolumex.O.QyC I DEntity /Common' 
EXECUTE usp PSPriceCostAII ©GasMonthx.QWhichVolumex.gyCIDEntity.O/Common' 

r 



* Calculate Transport contract gas inventory 

* items (create them along with any 

* transport deals). 

EXECUTE usp_PSPriceTransportAII @GasMonthx,@WhichVoiumex,0,@yCIDEntity 
7 

r 

* Indicate that the gas month is finished 

* and commit the updates. 

7 

UPDATE 

rGasMonth 
SET 

LockedUser=" 

WHERE 

GasMonth=@GasMonthx 
r „ ^ uuuiumumum 

* Check to make sure that any items that 

* require an invoice number gets created. 

* This is only applicable when the gas month 

* is in an 'Invoiced' state already. This 

* picks up any new deals/meters created 

* after the gas month promoted to 'Invoiced'. 

7 

IF (@yCurrentStatus- Invoiced') 
BEGIN 

EXECUTE usp_PSPriceAnyNewlnvoicesNeeded @yGasMonth,@yCIDEntity 
END 

FETCH NEXT FROM GasMonthCursor INTO @yGasMonth,@yCuiTentStatus 

END 

CLOSE GasMonthCursor v 

DEALLOCATE GasMonthCursor 

FETCH NEXT FROM EntityCIDCursor INTO @yCIDEntity 

END 

CLOSE EntityCIDCursor 
DEALLOCATE EntityCIDCursor 
END 
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40 



45 



50 



GO 

SET QUOTEDJDENTIFIER OFF SET ANSIJMULLS ON 
GO 

SET QUOTEDJDENTIFIER OFF SET ANSI.NULLS ON 
GO 



CREATE PROCEDURE usp_PSPriceComponentsCheck( 

@PIDx INTEGER, 
©WhichPricex INTEGER, 
©GasMonthx DATETIME, 

15 ©DBCRx INTEGER 



AS 

BEGIN 

r 

Name: usp_PSPriceComponentsCheck 
Description: 



25 Create any system generated pricing components automatically. Any existing 

O system generated pricing components are deleted. Then they are recreated 

g3 within this particular process. This procedure should be invoked for all 

?5 packages that were created within a given gas month. Current System 

Generated Items include price components tagged as 'NETBACK PERCENTAGE' or 

tO 30 'WASP'. 

U Inputs: 

LJ 

1^1: PIDx - Package Identifier 

j ; 35 WhichPricex - 0=Nominations, 1=Actuals 

r ~ GasMonthx - Gas Month for Price Calculations 

? DBCRx - 0=Purchase, 1 =Sales 



History: 

05/12/1999 JAMIE Original Creation. 

07/28/2000 JAMIE Modify this process so that OIL, GAS or LIQUIDS is used when 
obtaining the netback percentage. This is based on the product ID for the deal. 

08/17/2000 JAMIE Modify the process to eliminate any pricing entries on 
WASP/EQUITY deals ('Common' pool). This will ensure that the only pricing 
entries on the wasp deals are those that are system generated. 



* Declare all variables and cursors 
55 * that are needed by this process. 

7 

DECLARE ©zProductID INTEGER 
DECLARE ©zProductNetbackType VARCHAR(12) 
60 DECLARE ©yWasplndicator VARCHAR(10) 

DECLARE @yEngineMasterRecords INTEGER 
DECLARE @yEngineMasterETID_Key INTEGER 
DECLARE @yEngineMasterPriceSequence INTEGER 
DECLARE ©yNetBackPercentage DECIMAL(19 P 8) 

65 

DECLARE ETIDCursor CURSOR LOCAL STATIC FORWARD.ONLY FOR 
SELECT 

DISTINCT 
ETID 

70 FROM 
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Engine_Master 

WHERE 

PID=@PIDx 

r 



* Get the WASP indicator for this 

* particular deal via a function call. 

* This is based on how the deal is 

* classified. 



7 

EXECUTE uspJGetWasplndicator @PIDx ( @yWasplndicator OUTPUT 

r 



* Ail deals should have system generated 

* price entries removed here... 

* In addition, 'Common' wasp pool deals 

* will have all non system generated 

* price entries removed. Only purchase 

* deals are impacted by system generated 

* entries. 



V 

OPEN ETIDCursor 

FETCH NEXT FROM ETIDCursor INTO @yEngineMasterETID_Key 
WHILE @@FETCH_STATUS = 0 
BEGIN 

IF @yWasplndicator='Common' 
BEGIN 

IF @DBCRx=0 

BEGIN 

DELETE 

FROM 

Engine_MasterPrice 

WHERE 

(Engine_MasterPrice.ETID=@yEngineMasterETID_Key) AND 

(Engine MasterPrice.NomOrActual=@WhichPricex) 

END 

END 

ELSE 

BEGIN 

DELETE 

FROM 

Engine_MasterPrice 

WHERE 

(Engine_MasterPrice.ETID=@yEngineMasterETID_Key)AND 
(Engine_MasterPrice.NomOrActual=@WhichPricex) AND 
(Engine_MasterPrice.PriceTag=ANY(SELECT PriceTag FROM 

PriceComponents WHERE SystemGenerated=Y)) 
END 

FETCH NEXT FROM ETIDCursor INTO @yEngineMasterETID_Key 

END 

CLOSE ETIDCursor 
DEALLOCATE ETIDCursor 

r 



* Now generate (insert) the price 

* components that are required. These 

* system generated price components are 

* recognized by the PriceTag name. There 

* should be a section within this procedure 

* specifically for any system generated 

* pricing components. 



7 

r 
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10 



15 



* "WASP" and "NETBACK PERCENTAGE" 

* These two compononents go hand-in-hand. 
* 

* 1. Only system generate these if it is 

* a purchase task and the deal is considered 

* 'Wasp'able. 

*/ 

IF ({@yWasplndicator= , Common , ) OR (@yWasplndicator='Dedicated')) AND (@DBCRx=0) 
BEGIN 

r ^ 

* Determine the correct product type in order 

* to get the correct contract netback 

* tier information. 



Pi 



Lb 
D 



20 



25 



30 



35 



40 



45 



50 



55 



60 



65 



70 



V 

EXECUTE uspJGetWaspType @PIDx,@zProductNetbackType OUTPUT 

r 



* Now go and find an Engine.Master record 

* to attach these components too. If one 

* is not found, then insert one. An 

* attempt to preserve the existing record 

* will ensure that nominations and pipe 

* line actuals will utilize the same 

* EngineJ/laster entity. 



7 

SELECT @yEngineMasterRecords = ISNULL((SELECT count(*) FROM engine_master 

WHERE PID=@PIDx AND 

Effective=@GasMonthx AND STID=8 AND VolLevel=0),0) 
IF @yEngineMasterRecords=0 
BEGIN 

INSERT 

INTO 

Engine.Master 

(PlD.Effective.STID^olLevel.VolGroup.VarFixed.MMBtuMCF.TierThreshold) 

VALUES 

(@PIDx l @GasMonthx,8 l 0 ) @PIDx,1,1,1) 

END 

SELECT @yEngtneMasterETID_Key = ISNULL((SELECT MIN(ETID) FROM Engine.Master 

WHERE PID=@PIDxAND 

Effective=@GasMonthx AND STID=8 AND VolLevel=0),0) 

r ^ AAAAAAAAAAAAAAAAA 

At this point we now either have a valid 
ETID (key) to the Engine.Master or 0. 
There should be only a single record on 
the Engine.Master for these types of 
packages. 

Now insert the 'WASP' price component. 

IF @yEngineMasterETID_Key > 0 
BEGIN 

SELECT ©yEngineMasterPriceSequence = ISNULL((SELECT MAX(SequenceNo) FROM 



Engine.MasterPrice 

ETID=@yEngineMasterETID_Key AND NomOrActual=@WhichPricex),0) 

SELECT @yEngineMasterPriceSequence = @yEngineMasterPriceSequence+1 
INSERT 

INTO 

Engine.MasterPrice 

(ETID.PriceTag.OperandVariable.PriceVariable.CreateUser.CreateDate.LastUpdateUser, 

LastUpdateDate.SequenceNo.NomOrActual) 



WHERE 
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VALUES 

(@yEngineMasterETID_Key;WASP , ;+VWASP',UPPER(user_name()) t 



getdate(),UPPER(user_name()) ( getdate() p @yEngineMasterPric»Sequence,@WhichPricex) 
END 

r 



* Now invoke the 'NETBACK PERCENTAGE' 

* calculation routine and then insert this 

* particular price component Remember to 

* put the netback percentage into its 

* 'string' representation. 



7 

IF <3>yEngineMasterETID Key > 0 
BEGIN 

EXECUTE uspJGetNetbackPercentage 
@PlDx,@GasMonthx,@zProductNetbackType,@WhichPricex t @yNetBackPercentage OUTPUT 

IF QyNetBackPercentage IS NULL 
BEGIN 

SELECT ©yNetBackPercentage = 0 

END 

SELECT @yEngineMasterPriceSequence = @yEngineMasterPriceSequence+1 
INSERT 

INTO 

Engine.MasterPrice 

(ETID.PriceTag.OperandVariable.PriceVariable.CreateUser, 

CreateDate.LastUpdateUser.LastUpdateDate.SequenceNo.NomOrActual) 

VALUES 

(@yEngineMasterETID_Key,'NETBACK 

PERCENTAGE , r i LTRIM(STR(@yNetBackPercentage 1 8,4)) ( 

UPPER(CURRENT_USER) 1 getdate(),UPPER(CURRENT_USER),getdate(),@yEngineMaste[Pto 
END 

END 

END 



GO 

SET QUOTEDJDENTIFIER OFF SET ANSI NULLS ON 
GO 

SET QUOTEDJDENTIFIER OFF SET ANSI.NULLS ON 
GO 

CREATE PROCEDURE usp_PSPriceCost( 

©GasMonthx DATETIME, 
©WhichPricex INTEGER, 
@PKGx INTEGER, 
@STIDx INTEGER, 
@PCIDx INTEGER, 
@TIDx INTEGER, 
@CostLevelxVARCHAR(12), 
@CostBasisxVARCHAR(40), 
@CostRateOrAmountx DECIMAL(19,6), 
©TotalVolumex DECIMAL(19,2), 
@MeterVolumex DECIMAL(19,2) 
) 

AS 

BEGIN 

r 



Name: usp.PSPriceCost 
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Description: This particular procedure will perform the actual calculations and post 
updates to the engine table (for other costs associated with deals). This is done 
for each meter within a deal for an other cost item. 

Inputs: 

GasMonthx (Gas Month to cost) 

WhichPricex (0=Nominations, ^Actualizations) 

PKGx (deal id) 

STIDx (engine transaction id) 

PCIDx (deal other cost unique id (see PackageCosts table) 

TIDx (gas inventory identifier) 

Coslevelx (Level that cost is appropriated towards) 

CostBasisx (rules governing calculation of the cost) 

CostRateOrAmountx (rate or amount involved in cost) 

Total Volumex (total volume for deal) 

MeterVolumex (total volume for meter within deal). 

History: 

10/20/99 JAMIE Initial creation. 

03/26/00 JAMIE Modified to allow for zero volume deals to have other (fixed) costs 
assigned to them. 

10/03/20 JAMIE Modified to correct problem associated with 'METER' 
calculations using entire deal volume, 

12/01/2000 JAMIE Modified to apply the netback percentage to the other 
cost when it is calculated. This percentage is only applicable to purchase 
deals that are in the 'Common' or 'Dedicated' pools. 

1 2/10/2000 JAMIE Modified to check for the apply netback flag on the 
cost record in order to determine if the netback percentage should be 
applied to the cost. 



7 

r 



* Declare all variables and cursors 

* that are needed by this process. 

7 

DECLARE ©zNetbackPercent DECIMAL(19,6) 
DECLARE ©zProductNetbackType VARCHAR(12) 
DECLARE ©yWasplndicator VARCHAR(10) 
DECLARE ©zDBCR INTEGER 
DECLARE ©zApplyNetback VARCHAR(1) 

DECLARE ©zPercentToApply DECIMAL(19,4) 
DECLARE ©zAmountToApply DECIMAL(19,2) 
DECLARE ©zTotalSaleOrPurchValue DECIMAL(19,2) 
DECLARE ©zTotalMeters INTEGER 

r 



* Initialize any fields required. 



7 

SELECT @zNetbackPercent=0 
SELECT @zAmountToApply=0 
SELECT @zPercentToApply=1 
SELECT @zTotalSaleOrPurchValue=0 

r 

* Get the WASP indicator for this 

* particular deal via a function call. 

* This is based on how the deal is 

* classified. 
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V 

EXECUTE uspJGetWasplndicator @PKGx,@yWasplndicator OUTPUT 

SELECT @zDBCR=ISNULL((SELECT packagedbcr FROM package WHERE pkg=@PKGx),0) 

SELECT @zApplyNetback=lSNULL((SELECT applynetback from packagecosts WHERE pcid=@PCIDx), Y) 

/* 



* Determine the correct product type in order 

* to get the correct contract netback 
10 * tier information. 

*/ 

IF @zDBCR=0 

BEGIN 

15 IF (@yWasplndicator='Common') OR (@yWasplndicator='Dedicated') 

BEGIN 

EXECUTE usp JGetWaspType @PKGx,@zProductNetbackType OUTPUT 
EXECUTE uspJGetNetbackPercentage 
©PKGx.gGasMonthx.gzProductNetbackType.QWhicnPricex.gzNetbackPercent OUTPUT 
20 END 
END 

/* 



* Determine the percentage of whatever the 
25 * cost will calculate to here. 

* involved with this calculation. If it 

* is a deal level fixed cost then show 

* zeros IF there is no volume. 



A 30 */ 

lp IF (@MeterVolumex<>0) AND (@TotalVolumex<>0) 

~ BEGIN 

M IF @Coslevetx=*DEAL' 

U* BEGIN 

L 35 SELECT 

@zPercentToApply=CONVERT(DECI^ 
s END 

y* END 

5 z IF (@MeterVolumex = 0) AND (@Coslevelx='DEAL') 

!% ? 40 BEGIN 

bi SELECT @zPercentToApply=0 

M* END 

45 * If the cost is a FIXED AMOUNT and there 

* is no volume for the deal then determine 

* the amount to apply based on the number 

* of meters involved in the deal. If 1 

* meter only then 100% of cost assessed to 
50 * that meter. If 2 meters then 50% assessed 

* to each one. etc.. 



*/ 

IF (@MeterVolumex=0) AND (@TotalVolumex=0) 
55 BEGIN 

IF ©CostBasisx- Fixed Amount 1 
BEGIN 

SELECT @zTotalMeters=ISNULL((SELECT countO FROM Gaslnv WHERE PKG=@PKGx 

AND GasMonth=@GasMonthx) ( 0) 
60 IF ©zTotalMeters <> 0 

BEGIN 

SELECT 

@zPercentToApply=(1/CONVERT(DECIMAL(19 ( 4),@zTotalMeters)) 

SELECT 

65 @zAmountToApply=(@CostRateOrAmountx*@zPercentToApply) 

END 

END 

END 

r 

"J Q *************** 
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* Calculate based on fixed amount 

* here... Since this is a fixed amount 

* then the amount should be calculated 

* proportionately based on the total 

* volume percentage to the deal. 



*/ 

IF @CostBasisx- Fixed Amount 
BEGIN 

IF (@CostRateOrAmountx<>0) AND (@zPercentToApply<>0) 
BEGIN 

SELECT @zAmountToApply=(@CostRateOrAmountx*@zPercentToApply) 

END 

END 

r 



* Calculate based on a rate applied 

* against MMBTU's here... Regardless 

* of whether or not this is a 'DEAL' 

* level or 'METER' level charge the 

* cost should be based on meter 

* volume. 

7 

IF (@MeterVolumex<>0) 
BEGIN 

IF @CostBasisx='Rate Applied to MMBTUs' 
BEGIN 

IF (@CostRateOrAmountx<>0) 
BEGIN 

SELECT 

@zAmountToApply=((CONVERT(DECIMAL(19,4),@MeterVolumex)*@CostRateOrAmountx)) 

END 

END 

END 

r 



* Calculate based on the total dollar amount 

* previously calculated here.., Since 

* this particular cost is calculating on 

* just the amount for the associated 

* meter (ie.. sum of engine based on 

* TID) then the 'PercentToApply' is 

* not applicable. 

•/ 

IF (@MeterVolumex<>0) AND (@TotalVolumex<>0) 
BEGIN 

IF @CostBasisx-Rate Applied to Value' 
BEGIN 

IF @WhichPricex=0 
BEGIN 

SELECT @2TotalSaleOrPurchValue=ISNULL((SELECT SUM(amount) 

FROM engine WHERE tid=@tidx AND (stid=8 OR stid=9)),0) 

END 

IF @WhichPricex=1 
BEGIN 

SELECT @zTotalSaleOrPurchValue=ISNULL((SELECT 
SUM(amountact) FROM engine WHERE tid=@tidx AND (stid=8 OR stid=9)),0) 

END 

if(@CostRateOrAmountx<>0) AND (@zTotalSaleOrPurchValue<>0) 
BEGIN 

SELECT 

@zAmountToApply=(@zTotalSaleOrPurchValue*@CostRateOrAmountx) 

END 

END 

END 

r 



* Finally, post the cost amount to the 
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* Engine table. If the engine table for 

* this transaction does not yet exist then 

* insert it otherwise just update it... 

* Make sure that actual calculations and 

* nomination calculations are done within 

* their respective 'buckets'. 



r 



* First apply the netback if it 
*is there AND if the apply 

* netback flag has been set 

* on the cost item. 

*/ 

IF ©zApplyNetback = T 
BEGIN 

IF @zNetbackPercent<>0 
BEGIN 

SELECT @zAmountToApply=ROUND((@zAmountToApply*@zNetbackPercent) P 2) 

END 

END 

r 



* Apply and post the amount 

* here... 



7 

IF @WhichPricex=0 
BEGIN 

IF (SELECT countO FROM Engine WHERE TID=@TIDx AND STID=@STIDx AND Effective=@GasMonthx AND 

VolLevel=0)=0 

BEGIN 

INSERT 

INTO 

Engine 

(TID,STID,Effectwe ( VolLevelW 

TID) 

VALUES 

(@TIDx,@STIDx t @GasMonthx l 0,@PKGx,1 ) 0 l ROUND(@zAmountToApply,2) f 0,0 I 0 l 0,@PCIDx) 
END 

ELSE 

BEGIN 

UPDATE 

engine 
SET 

Amount=Amount+ROUND(@zArnountToApply,2) 

WHERE 

TID=@TIDx AND 
STID=@STIDxAND 
Effective=@GasMonthx AND 
VolLevel=0 

END 

END 

IF @WhichPricex=1 
BEGIN 

IF (SELECT countO FROM Engine WHERE TID=@TIDx AND STID=@STIDx AND Effective=@GasMonthx AND 

Vo!Level=0)=0 

BEGIN 

INSERT 

INTO 

Engine 

{TID,STID,Effectwe,VolLevel,VolGrou& 

TID) 

VALUES 
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(@TIDx ) @STIDx,@GasMonmx I 0,@PKGx ) 1 J 0,0,0,0,0,ROUND(@zAmountToAppty,2),@PCIDx) 
END 

ELSE 

BEGIN 

UPDATE 



engine 
SET 

WHERE 



END 



END 



END 



GO 

SET QUOTEDJDENTIFIER OFF SET ANSI NULLS ON 
GO 

SET QUOTED IDENTIFIER OFF SET ANSI.NULLS ON 
GO 



AmountAct=AmountAct+ROUND(@zAmountToApply,2) 

TID=@TIDx AND 
STID=@STIDxAND 
Effective=@GasMonthx AND 
VolLevel=0 



CREATE PROCEDURE usp_PSPriceCostAII( 



AS 

BEGIN 

r 



@GasMonthx DATETIME, 
©WhichPricex INTEGER, 
@EntityCIDx VARCHAR(12), 
@DBCRx INTEGER, 
©IncludelnWaspx VARCHAR(10) 
) 



Name: usp_PSPriceCostAII 

Description: Loop thruough all other costs associated to deals within a given month 
then apply the cost to the dean (posting engine records reflecting the cost amounts), 
or sale) and invoke the price procedures. 

Inputs: 

GasMonthx - Gas Month to price), 

WhichPricex - 0=Nominations, ^Actualizations 

EntityCIDx - owning entiry company identifier 

DBCRx - 0=Purchases, 1=Sales (deals) 

IncludelnWaspx = " for all or specific pool (ie. 'Common', etc.). 

History: 

10/20/99 JAMIE Initial creation. 



03/26/00 JAMIE Modified to allow for zero volume deals to have other (fixed) costs 
assigned to them. 

05/24/2000 JAMIE Modified to make sure that the calculation was within a specific 
entity. 

10/03/2000 JAMIE Modified to accept two additional parameters to dictate which 
pool and whether or not purchases or sales were to be calculated upon... 
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r 



Declare all variables and cursors 
that are needed by this process. 



n 



10 



15 



20 



25 



30 



35 



40 



45 



50 



55 



60 



65 



70 



7 

DECLARE 
DECLARE 
DECLARE 
DECLARE 
DECLARE 
DECLARE 



@zMessageVARCHAR(254) 
©zTotalVolume DECIMAL(19,2) 
©zMeterVolume DECIMAL(19,2) 
©zVolumeStatus INTEGER 
©zPriceStatus INTEGER 
©zlncludelnWasp VARCHAR(IO) 



DECLARE @yPCID INTEGER 

DECLARE @yPKG INTEGER 

DECLARE @ySTID INTEGER 

DECLARE ©yCoslevel VARCHAR(12) 

DECLARE ©yCostMID INTEGER 

DECLARE ©yCostBasis VARCHAR(40) 

DECLARE ©yCostRateOrAmount DECIMAL(19,4) 

DECLARE @wT!D INTEGER 
DECLARE @wNom DECIMAL(19,2) 
DECLARE ©wPipelineActuals DECIMAL(19,2) 
DECLARE @wGaslnv_MID INTEGER 

DECLARE ©eETID INTEGER 
DECLARE ©eVolume DECIMAL(19,2) 
DECLARE ©ePriceOrRateNom DECIMAL(19,6) 
DECLARE @eVolumeActDECIMAL(19,2) 
DECLARE @ePriceOrRateActDECiMAL(19,6) 
DECLARE ©evolumestatus INTEGER 
DECLARE ©epricestatus INTEGER 
DECLARE @ePKG INTEGER 

DECLARE PackageCostsCursor CURSOR LOCAL STATIC FORWARD_ONLY FOR 
SELECT 

PackageCosts.PCID, 

PackageCosts.PKG, 

PackageCosts.STID, 

PackageCosts.CostLevel, 

PackageCosts.CostMID, 

PackageCosts.CostBasis, 

PackageCosts.CostRateOrAmount 

FROM 

PackageCosts 

WHERE 

PackageCosts.PKG=ANY(SELECT PKG FROM Package.k WHERE PackageGasMonth=@GasMonthx AND 

K.KID=Package.KID AND K£ntityCID=@EntityCIDx AND 

Package.PackageDBCR=@DBCRx) 
ORDER BY 

PackageCosts.PKG, 
PackageCosts.STID 

DECLARE EngineCursor CURSOR LOCAL STATIC FORWARD.ONLY FOR 
SELECT 

engine.etid, 
engine.volume, 
engine.priceorratenom, 
engine.volumeact, 
engine.priceorrateact, 
engine.volumestatus, 
engine.pricestatus, 
package, pkg 



FROM 



WHERE 



engine, 
gasinv, 
package, 
k 
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package. pkg=gasinv.pkg AND 
k.kid=package.kid AND 
k.entitycid=@entitycidx AND 
gasinv.gasmonth=@GasMonthx AND 
engine.tid=gasinv,tid AND 
gasinv.pricetype=1 AND 
gasinv.dbcr=@DBCRx 



* Loop through each other package cost 

* involved with this calculation. 



SELECT @zTotalVolume=ISNULL((SELECT SUM(Nom) FROM 



V 

SELECT @zMessage = 'PSPriceCostAII Running To Calculate Other Costs for all Deals' 
EXECUTE usp_Message @zMessage 
OPEN PackageCostsCursor 

FETCH NEXT FROM PackageCostsCursor INTO ©yPCID.QyPKG.gySTID.QyCoslevel.QyCostMID.gyCostBasis.gyCostRateOrAmount 
WHILE @@FETCH_STATUS = 0 
BEGIN 

BEGIN TRANSACTION 

r 

********************************+********* 

* Sum the appropriate volumes for this 

* deal depending on whether nominations are 

* being calculated OR pipeline actuals are 

* begin calculated. 

*/ 

SELECT ©zMessage = 'PSPriceCostAII Calculating Costs for Deal...' + CAST(@yPKG AS VARCHAR(10)) 
EXECUTE usp.Message ©zMessage 

EXECUTE uspJGetWasplndicator @yPKG ( @zlncludelnWasp OUTPUT 
IF (@lncludelnWaspx=") OR (@lncludelnWaspx=@zlncludelnWasp) 
BEGIN 

IF @WhichPricex=0 
BEGIN 

Gaslnv WHERE Gaslnv.PKG=@yPKG AND Gaslnv.PriceType=1),0) 

END 

IF @WhichPricex=1 
BEGIN 

SELECT @zTotalVolume=ISNULL((SELECT SUM(PipelineActuals) 
FROM Gaslnv WHERE Gaslnv.PKG=@yPKG AND Gaslnv.PriceType=1),0) 

END 

L* ********* 

* Open a cursor on all meters associated 

* with this deal. 

*/ 

DECLARE GaslnvCursor CURSOR LOCAL STATIC FORWARD.ONLY FOR 
SELECT 

Gaslnv.TID, 

Gaslnv.Nom, 

Gaslnv.PipelineActuals, 

Gaslnv.Gaslnv_MID 

FROM 

Gaslnv 

WHERE 

Gaslnv.PKG=@yPKG AND 
Gaslnv.PriceType=1 

OPEN GaslnvCursor 

FETCH NEXT FROM GaslnvCursor INTO @wTID,@wNom,@wPipelineActuals P @wGaslnv_MID 
WHILE @@FETCH_STATUS = 0 
BEGIN 

r **** *********** 

* Depending on which pricing routine is 

* run, set the appropriate meter volume 

* field. 
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*/ 

IF @WhichPricex=0 

BEGIN 

SELECT @zMeterVolume=@wNom 
END 

IF @WhichPricex=1 

BEGIN 

SELECT @zMeterVolume=@wPipelineActuals 
END 

r 



* Invoke the detail cost routine in order 

* to calculate and post the cost totals 

* to the Engine Database. 

V 

IF (@yCostLevel-DEAL') OR (@yCoslevel- METER' AND 

@yCostMID=@wGaslnv_MlD) 

BEGIN 

EXECUTE usp.PSPriceCost 

@GasMonthx t @WhichPricex ) @yPKG,@ySTID,@yPCID 1 

@wTID,@yCoslevel,@yCostBasis,@yCostRateOrAmount, 
@zTotalVolume,@zMeterVolume 

END 

FETCH NEXT FROM GaslnvCursor INTO 

@wTID,@wNom ( @wPipelineActuals,@wGaslnv_MID 

END 

CLOSE GaslnvCursor 
DEALLOCATE GaslnvCursor 

END 

COMMIT WORK 

FETCH NEXT FROM PackageCostsCursor INTO 
©yPCID.gyPKG.gySTID.QyCoslevel.QyCostMID.QyCostBasis.gyCostRateOrAmount 
END 

CLOSE PackageCostsCursor 
DEALLOCATE PackageCostsCursor 

r 



* Loop through and set the status flags 

* on the engine record IF the price or 

* volumes or amounts are different 

* between noms and actuals. Make 

* sure the logic exists to only calculate 

* those deals (purchases or sales) 

* within the correct WASP pool. 

*/ 

IF @WhichPricex=1 
BEGIN 

SELECT @zMessage = 'PSPriceCostAII Running To Set Price & Volume Variance Status Indicators...' 
EXECUTE usp_Message @zMessage 
OPEN EngineCursor 
FETCH NEXT FROM EngineCursor INTO 
@eETID,@eVolume,@ePriceOrRateNom,@eVo1umeAtf,@^ 
WHILE @@FETCH_STATUS = 0 
BEGIN 

EXECUTE uspJGetWasplndicator @ePKG,@zlncludelnWasp OUTPUT 
IF (@lncludelnWaspx=") OR (@lncludelnWaspx=@zlncludelnWasp) 
BEGIN 

* Check prices and volumes here. 



SELECT @zVolumeStatus=0 
SELECT @zPriceStatus=0 
IF @eVolume<>@eVolumeAct 
BEGIN 
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SELECT @zVolumeStatus=1 
END 

IF @ePriceOrRateNom<>@ePriceOrRateAct 
BEGIN 

SELECT @zPriceStatus=1 
END 

IF (@zVolumeStatus<>@eVolumeStatus) OR (@zPriceStatus<>@ePriceStatus) 
BEGIN 



UPDATE 



engine 
SET 



volumestatus=@zVolumeStatus, 
pricestatus=@zPriceStatus 



END 



END 



WHERE 



FETCH NEXT FROM EngineCursor INTO 
@eVolume,@ePriceOrRateNom,@eVolumeAct t @^ 
END 

CLOSE EngineCursor 
DEALLOCATE EngineCursor 

END 



END 



ETID=@eETID 



GO 

SET QUOTEDJDENTIFIER OFF SET ANSI.NULLS ON 
GO 

SET QUOTED IDENTIFIER OFF SET ANSI NULLS ON 
GO 

CREATE PROCEDURE usp_PSPriceCreateActualEntries( 

©GasMonthx DATETIME 
) 

AS 

BEGIN 

SET NOCOUNT ON 

r 



Name: usp_PSPriceCreateActualEntries 

Description: This routine will clear out any existing links and pricing enties 
that may have already been setup for pipeline actuals. It will then copy the 
nominiation pricing and linking entries for pipeline actuals (within the given 
month). This process should only get invoked with the status of a given month 
within the gas control system goes from 'Sales' to 'Invoiced' at that point in time 
the accounting group will be responsible for any further modifications. 

Inputs: 

GasMonthx (Gas Month to calculate), 
History; 

08/04/1999 JAMIE Original creation 

08/25/2000 JAMIE Modified to remove the PackageLinks delete and build 
logic (replaced by new routing structures). 



*/ 

r 
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* Declare all variables and cursors 

* that are needed by this process. 



V 

DECLARE ©zMessage VARCHAR(254) 
DECLARE @yPKG INTEGER 
DECLARE ©yETID INTEGER 
DECLARE @yEM_ETID INTEGER 

r 



* Clear out the link and price entry 

* structures for the specified month 

* here... These entries will be 

* recreated (from Norn side) in the 

* next step. 

* Database triggers take care of the 

* individual pricing components in 

* the Engine.MasterPrice table. 

7 

SELECT @zMessage = 'PSPriceCreateActualEntries, removing Engine.MasterPrice...' 
EXECUTE usp_Message @zMessage 

DECLARE Engine JvlasterDeleteCursor CURSOR LOCAL STATIC FORWARD.ONLY FOR 
SELECT 

DISTINCT 

(Engine_Master.ETID) 
FROM 

Engine_Master, 
Gaslnv, 

Engine_MasterPrice 

WHERE 

Gaslnv.GasMonth=@GasMonthx AND 
Gaslnv.PriceType=1 AND 
Gaslnv.PKG=Engine_Master.PID AND 
Engine_MasterPrice.ETID=Engine_Master.ETID AND 
Engine_MasterPrice.NomOrActual=1 

OPEN Engine.MasterDeleteCursor 

FETCH NEXT FROM Engine_MasterDeleteCursor INTO @yEM_ETID 
WHILE @@FETCH_STATUS = 0 
BEGIN 

BEGIN TRANSACTION 

SELECT @zMessage = 'PSPriceCreateActualEntries, actual Engine_MasterPrice removed...' 

EXECUTE usp_Message @zMessage 

DELETE 

FROM 

Engine_MasterPrice 

WHERE 

ETID=@yEM_ETID AND 
NomOrActual=1 

COMMIT WORK 

FETCH NEXT FROM Engine.MasterDeleteCursor INTO @yEM_ETlD 

END 

CLOSE Engine_MasterDeleteCursor 
DEALLOCATE Engine.MasterDeleteCursor 

r 



* Now bulk populate the engine 

* pricing information. Taking nom 

* pricing entries and creating actual 

* pricing entries. 



*/ 

SELECT ©zMessage = 'PSPriceCreateActualEntries, running Gaslnv cursor...' 
EXECUTE usp_Message ©zMessage 

DECLARE GaslnvCursor CURSOR LOCAL STATIC FORWARD.ONLY FOR 
SELECT 

DISTINCT 
(Gaslnv.PKG) 
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FROM 

Gaslnv 

WHERE 

Gaslnv.GasMonth=@GasMonthx AND 
Gaslnv.PriceType=1 

OPEN GaslnvCursor 

FETCH NEXT FROM GaslnvCursor INTO @yPKG 
WHILE @@FETCH_STATUS = 0 
BEGIN 

BEGIN TRANSACTION 

SELECT ©zMessage = 'PSPriceCreateActualEntries, obtaining price entries for Gaslnv Package...' 
EXECUTE usp_Message ©zMessage 

DECLARE Engine_MasterCursor CURSOR LOCAL STATIC FORWARD.ONLY FOR 
SELECT 

DISTINCT 

(ETID) 

FROM 

Engine_Master 

WHERE 

PID=@yPKG 

OPEN Engine.MasterCursor 

FETCH NEXT FROM EngineJvlasterCursor INTO ©yETID 
WHILE @@FETCH_STATUS = 0 
BEGIN 

SELECT ©zMessage = 'PSPriceCreateActualEntries, inserting actual prices...' 

EXECUTE usp_Message ©zMessage 

INSERT 

INTO 

Engine.MasterPrice 

(ETID.PriceTag, Operand Variable, PriceVariable.CreateUser, 

CreateDate,LastUpdateUser,LastUpdateDate,SequenceNo,NomOrActual) 

(SELECT 

ETID.PriceTag.OperandVariable.PriceVariable.CreateUser.CreateDate.LastUpdateUser.LastUpdateDate, 

SequenceNo,1 FROM Engine.MasterPrice WHERE ETID=@yETID 

AND NomOrActual=0) 

FETCH NEXT FROM Engine.MasterCursor INTO ©yETID 

END 

CLOSE Engine.MasterCursor 
DEALLOCATE Engine.MasterCursor 
COMMIT WORK 

FETCH NEXT FROM GaslnvCursor INTO ©yPKG 

END 

CLOSE GaslnvCursor 
DEALLOCATE GaslnvCursor 
END 



GO 

SET QUOTEDJDENTIFIER OFF SET ANSI.NULLS ON 
GO 

SET QUOTEDJDENTIFIER OFF SET ANSI.NULLS ON 
GO 

CREATE PROCEDURE usp_PSPriceMarkActualAdjustments( 

©GasMonthx DATETIME 
) 

AS 

BEGIN 

SET NOCOUNTON 

r 



Name: usp.PSPriceMarkActualAdjustments 

Description: This routine will go through each inventory (and engine 
records) in order to identify and mark those records that had some sort of 
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an actualization adjustment (price or volume). The invoice number for sales 
will get reset to a 'A' (last character) if it currently exists as an 'N\ 

Inputs: 

GasMonthx (Gas Month to calculate), 
History: 

12/15/1999 JAMIE Original creation 



7 

r 



* Declare all variables and cursors 

* that are needed by this process. 

*/ 

DECLARE ©zMessage VARCHAR(254) 

DECLARE ©yAcctgldentifier VARCHAR(12) 
DECLARE @zAcctgldentifier VARCHAR(12) 
DECLARE ©zLastChar VARCHAR(1) 
DECLARE @zlnvoiceLength INTEGER 

DECLARE @qTID INTEGER 

/* 



* First set the modified by actuals flag 

* across the board for all gasinventory 

* items that have a price type of '1 ' 

* (this includes 'Other Costs'. 

* The defaults is set to 'N' then go 

* and override with changes. 



*/ 

SELECT @zMessage = ***** STARTED PSPriceMarkActualAdjustments' 
EXECUTE usp Message @zMessage 

DECLARE GaslnvlCursor CURSOR LOCAL STATIC FORWARDJDNLY FOR 
SELECT 

TID 
FROM 

Gaslnv 

WHERE 

GasMonth=@GasMonthx AND 
PriceType = 1 

OPEN GaslnvlCursor 

FETCH NEXT FROM GaslnvlCursor INTO @qTID 
WHILE @@FETCH STATUS = 0 
BEGIN 

BEGIN TRANSACTION 
UPDATE 

Gaslnv 
SET 

Modified ByActuals-N* 

WHERE 

TID = @qTID 

COMMIT WORK 

FETCH NEXT FROM GaslnvlCursor INTO @qTID 

END 

CLOSE GaslnvlCursor 
DEALLOCATE GaslnvlCursor 

r 



* At this point all of the gas inventory 

* items that have had some sort of 

* modification done on them between 
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* noms and actuals will have been 

* updated to a Y. Now go and reset 

* the accounting identifier for each of 

* these records. 



*/ 

SELECT ©zMessage = 'PSPriceMarkActualAdjustments, make any modifiications' 
EXECUTE usp Message ©zMessage 

DECLARE Gaslnv2Cursor CURSOR LOCAL STATIC FORWARD.ONLY FOR 
SELECT 

DISTINCT 
(GAcctg Identifier) 
FROM 

Gaslnv AS G, 
Engine AS E 

WHERE 

GasMonth=@GasMonthx AND 
G.PriceType=1 AND 
E.TID=G.TID AND 

(E.PriceStatusoO OR E.VolumeStatus<>0) 

OPEN Gaslnv2Cursor 

FETCH NEXT FROM Gaslnv2Cursor INTO ©yAcctg Identifier 
WHILE @@FETCH_STATUS = 0 
BEGIN 

BEGIN TRANSACTION ' 
/* 



* Make sure that it is a valid 6 digit 

* invoice number AND the sixth digit 

* contains an 'N' (for noms). 

* Update all if this criteria has been 

l^Lx ^ ^x^ui^^i^^* **** 

7 

SELECT @zlnvoiceLength=LEN(RTRIM(LTRIM(@yAcctgldentifier))) 
IF @zlnvoiceLength=6 
BEGIN 

SELECT @zAcctgldentifier=RTRIM(LTRIM(@yAcctgldentifier)) 
SELECT @2LastChaFRIGHT(@zAcctgldentifier,1) 
IF @zLastChar='N' 
BEGIN 

SELECT @zAcctgldentifieFLEFT(@zAcctgldentifier ( 5)+'A' 
UPDATE 

Gaslnv 
SET 

ModifiedByActuals=Y, 

Acctgldentifier=@zAcctg Identifier 

WHERE 

GasMonth=@GasMonthx AND 
Acctgldentifier=@yAcctg Identifier 

END 

END 

COMMIT WORK 

FETCH NEXT FROM Gaslnv2Cursor INTO ©yAcctg Identifier 

END 

CLOSE Gaslnv2Cursor 
DEALLOCATE Gaslnv2Cursor 

SELECT ©zMessage = ***** FINISHED PSPriceMarkActualAdjustments' 

EXECUTE usp.Message ©zMessage 

END 



GO 

SET QUOTED IDENTIFIER OFF SET ANSI NULLS ON 
GO 

SET QUOTEDJDENTIFIER OFF SET ANSI.NULLS ON 
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w 40 



GO 

CREATE PROCEDURE usp_PSPricePopulateEngine( 



@PIDx INTEGER, 
©WhichPricex INTEGER, 
@GasMonthx DATETIME, 
@DBCRx INTEGER 



AS 

10 BEGIN 

r 

***** 

Name: usp.PSPricePopulateEngine 

1 5 Description: Make sure that the price entries are populated on the engine 

master for the respective Enginejvlaster pricing records. Only those 
engine records with pricetype=1 (STID=8 or STID=9) will be manipulated by 
this process. 

20 Inputs: 

PIDx (unique Package ID) 
WhichPricex(0=Nomination, 1=Actual) 
GasMonthx (gas month calculation applicable toward) 
DBCRx (0=Purchase,1=Sale) 

25 

History: 

05/14/99 JAMIE Original Creation 

30 09/27/99 JAMIE Modify this process to check for index baskets AND IF the 

index basket is comprised of daily indices then populate the entire month 
with the basket information. 

01/27/00 JAMIE Modified to delete engine records while in the actuals phase 
35 if the nom information is zero (all nom information, price, volume, amount, etc.). 



* Declare all variables and cursors 
^ * that are needed by this process. 

V 

45 DECLARE ©dPriceEntryType VARCHAR(12) 

DECLARE ©dPriceVariable VARCHAR(15) 
DECLARE ©tmpDailylndexCount INTEGER 
DECLARE ©tmpUseEffective DATETIME 
DECLARE ©tmpEndDate DATETIME 
50 DECLARE ©tmpPrevEffective DATETIME 

DECLARE ©tmpNextEffectiveDate DATETIME 
DECLARE @tmpNumberDays DATETIME 
DECLARE ©tmpVolumelnPeriod DECIMAL(19,2) 
DECLARE ©tmpDateToUse DATETIME 
55 DECLARE ©tmpEndEffectiveDate DATETIME 

DECLARE @yETID INTEGER 
DECLARE ©yEffective DATETIME 
DECLARE ©ySTID INTEGER 
DECLARE ©yVolLevel INTEGER 
60 DECLARE ©yVolGroup INTEGER 

DECLARE ©yVarFixed INTEGER 
DECLARE ©yMMBtuMCF INTEGER 
DECLARE ©yTierThreshold INTEGER 

65 DECLARE @yTID INTEGER 

r 

* First, Go out and delete entries off the 
70 * engine database related to this particular 
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* package. If the pipeline actuals are 

* being processed then just go and 

* initialize any existing Engine record 

* 'Actual' buckets to zero (leave the 

* preexisting engine records intact). 
* 

* Modified on 01/27/2000 to delete engine 

* records off actuals IF there are no nom 

* numbers stored on the records... 



V 

IF @WhichPricex=0 
BEGIN 

DELETE 

FROM 

Engine 

WHERE 

TID=ANY(SELECT TID FROM Gaslnv WHERE PKG=@PIDx AND PriceType=1 AND 

DBCR=@DBCRx) 
END 

IF @WhichPricex=1 
BEGIN 

DELETE 

FROM 

Engine 

WHERE 

TID=ANY(SELECT TID FROM Gaslnv WHERE PKG=@PIDx AND PriceType=1 AND 

DBCR=@DBCRx) AND 

PriceOrRateNom=0 AND 
Volume=0 AND 
Amount=0 

UPDATE 

Engine 
SET 

PriceOrRateAct=0, 

VolumeAct=0, 

AmountAct=0 

WHERE 

TID=ANY(SELECT TID FROM Gaslnv WHERE PKG=@PIDx AND PriceType=1 AND 

DBCR=@DBCRx) 
END 

r 



* First, do a loop on all of the 

* Engine_Master records in order to 

* remove any that don't have any price 

* records associated to it.. (Orphans).. 

* A commit point is placed here in order to 

* insure that subsequent cursor activity 

* only picks up valid price records. 



7 

DECLARE Engine JviasterCursorl CURSOR LOCAL STATIC FORWARD.ONLY FOR 
SELECT 

em.ETID, 

em.Effective, 

em.STID, 

em.VolLevel, 

em.VolGroup, 

em.VarFixed, 

em.MMBtuMCF, 

em.TierThreshold 

FROM 

Engine Master AS em 

WHERE 

(em.PlD=@PIDx) 

ORDER BY 

em.Effective 

OPEN Engine_MasterCursor1 
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FETCH NEXT FROM Engine_MasterCursor1 INTO 

©yETID.gyEffe^ve.gySTID.QyVolLevel.gyVolGroup.gyVarFixed.gyMMBtuMCF.gyTierThreshold 
WHILE @@FETCH_STATUS = 0 
BEGIN 

IF ISNULL((SELECT count(*) FROM EngineJtasterPrice WHERE ETID=@yETID),0) < 1 
BEGIN 

DELETE 

FROM 

Engine_Master 

WHERE 

ETID=@yETlD 

END 

FETCH NEXT FROM Engine.MasterCursort INTO 
©yETID.gyEffective.QySTID.gyVolLevel.QyVolGroup.QyVarFixed.QyMMBtuMCF.QyTierThreshold 
END 

CLOSE Engine_MasterCursor1 
DEALLOCATE Engine_MasterCursor1 

r 



* Now loop through the existing 

* Engine.Master records. These are the 

* actual price entries that were input 

* by the user. There can be a record 

* PER DAY or a single record for the 

* entire month. Only 1 entry PER 

* Effective date will be stored within 

* the Engine table. That is why the 

* tmpPrevEffective is used within the 

* cursor process. 



7 

SELECT etmpPrevEffecfive^OI-OMSOO' 

DECLARE Engine_MasterCursor2 CURSOR LOCAL STATIC FORWARD.ONLY FOR 
SELECT 

em.ETID, 

em. Effective, 

em.STID, 

em.VolLevel, 

em.VolGroup, 

em.VarFixed, 

em.MMBtuMCF, 

em.TierThreshold 

FROM 

Engine Master AS em 

WHERE 

(em.PID=@PIDx) 

ORDER BY 

em. Effective 

OPEN Engine_MasterCursor2 

FETCH NEXT FROM Engine_MasterCursor2 INTO 

@yETID ( @yEffective ( @ySTID ( @yVolLevel,@yVolGroup,@yVarFixed,@yMMBtuMCF,@yTierThreshold 
WHILE @@FETCH_STATUS = 0 
BEGIN 

r 



Check for daily index entries... If they 
are found then go and calculate the 
end date for which to insert engine 
records (automating a daily price 
entry to the engine for each day of 
the month up thru the end of the month 
or to the next effective date. 

This will also check for index basket 
monthly entries. If the index basket 
contains daily indices then populate 
each day of the month just as if it 
was a daily index. 
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IF @yEffective<>@tmpPrevEffective 
BEGIN 

EXECUTE usp_fLastDay @GasMonthx,@tmpEndDate OUTPUT 
SELECT @tmpDailylndexCount=0 

5 DECLARE DailyCheckCursor CURSOR LOCAL STATIC FORWARD_ONLY FOR 

SELECT 

p.PriceEntryType, 
emp.PriceVariable 
FROM 

1 0 Engine_MasterPrice AS emp, 

PriceComponents AS p 

WHERE 

(emp.ETID=@yETID) AND 
(emp.NomOrActual=@WhichPricex) AND 
1 5 (p.PriceTag=emp.PriceTag) AND 

(p.PriceEntryType='Daily IDX' OR 

p.PriceEntryType- Basket IDX) 

OPEN DailyCheckCursor 
FETCH NEXT FROM DailyCheckCursor INTO @dPriceEntryType,@dPriceVariable 
20 WHILE @@FETCH_STATUS = 0 

BEGIN 

IF (@dPriceEntryType='Daily IDX') AND (@tmpDailylndexCount=0) 
BEGIN 

SELECT @tmpDailylndexCount=1 
25 END 

IF (@dPriceEntryType='Basket IDX') AND (@tmpDailylndexCount=0) 
BEGIN 

SELECT ©tmpDailylndexCount = ISNULL((SELECT 

count(*) FROM IndexBaskelinkJndexRef 

30 

WHERE (lndexBasketLink.lndexBasketlD=@dPriceVariable) AND 

(lndexRef.lndexlD=lndexBaskelink.lndexlD)AND 
35 (lndexRef.Dailylndex=1)),0) 

END 

FETCH NEXT FROM DailyCheckCursor INTO @dPriceEntryType p @dPriceVariable 
END 

CLOSE DailyCheckCursor 
40 DEALLOCATE DailyCheckCursor 

IF @tmpDailylndexCount=0 
BEGIN 

SELECT @tmpEndEffectiveDate=@yEffective 

END 

45 ELSE 

BEGIN 

SELECT @tmpEndEffectiveDate=ISNULL((SELECT DATEADD(day,- 

1 p MIN(em.effective)) FROM Engine_Master AS em 



WHERE 



50 (em.PID=@PIDx) AND (em.Effective>@yEffective)),@tnipEndDate) 

END 

r 

* Now insert the new Engine records. 
55 * These inserts will be based on a loop 

* between the effective date from the 

* Engine_Master record and the temp 

* field tmpEndEffectiveDate. This will 

* provide for the 'proliferation' of 
60 * daily index price entries (to the 

* engine). Only insert engine records 

* if there is some sort of volume 

* Norn or PipelineActual on associated 

* with a specific day. 



65 



70 



* If pipeline actuals then inserts do 

* not automatically happen. A check 

* is first made to see if the engine 

* record is already there... 
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SELECT @tmpUseEffective=@yEffective 
WHILE @tmpUseEffective <= ©tmpEndEffectiveDate 
BEGIN 

DECLARE GaslnventoryCursor CURSOR LOCAL STATIC 



FORWARD.ONLY FOR 



SELECT 



DISTINCT 

g.TlD 

FROM 



WHERE 



AND 

or(gd.PipelineActuals<>0)) 



AND STID=@ySTID AND 

Effective=@tmpUseEffective AND VolLevel=0)=0 

Engine 

(TID.STID.Effective.VolLevel.VolGroup.MMBtuMCF.EM.ETID) 

(©yTID.gySTID.QtmpUseEffective.O.QyVolGroup.gyMMBtuMCF.QyETID) 

ELSE 



EM_ETID=@yETID 



GaslnvASg, 
GaslnvD AS gd 

(gd.TID=gTID) AND 
(g.PID=@PIDx)AND 
(g.GasMonth=@GasMonthx) AND 
(g.PriceType=1)AND 
(g.DBCR=@DBCRx) AND 
(gd.GasDay>=@tmpUseEffective) 



((gd.Nom<>0) 

OPEN GaslnventoryCursor 

FETCH NEXT FROM GaslnventoryCursor INTO @yTID 
WHILE @@FETCH_STATUS = 0 
BEGIN 

IF (SELECT countO FROM Engine WHERE TID=@yTID 



BEGIN 



INSERT 



INTO 



VALUES 



END 
BEGIN 



UPDATE 



Engine 
SET 



WHERE 



TID=@yTlD AND 
STlD=@ySTID AND 
Effective=@tmpUseEffective AND 



VolLevel=0 



END 

FETCH NEXT FROM GaslnventoryCursor INTO @yTID 
END 

CLOSE GaslnventoryCursor 

DEALLOCATE GaslnventoryCursor 
SELECT @tmpUseEffective=DATEADD(day,1,@tmpUseEffective) 
END 



END 



SELECT @tmpPrevEffectrve=@yEffective 
FETCH NEXT FROM Engine_MasterCursor2 INTO 
@yETID,@yEffective t @ySTID,@yVolLevel,@yVolGroup,@yVarFixed,@yMMBtuMCF,@yTierThreshold 
END 

CLOSE Engine_MasterCursor2 
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45 



60 



DEALLOCATE Engine_MasterCursor2 
END 



10 GO 

SET QUOTEDJDENTIFIER OFF SET ANSI.NULLS ON 
GO 

SET QUOTEDJDENTIFIER OFF SET ANSI_NULLS ON 
15 GO 

CREATE PROCEDURE usp_PSPriceTransportAll( 

©GasMonthx DATETIME, 
©WhichPricex INTEGER, 
20 @PKGx INTEGER, 

@EntityCIDxVARCHAR(12) 
) 

AS 

BEGIN 

25 r 

Name: usp_PSPriceTransportAII 

Description: This is the main process for calculating the transport costs 
30 for all transport entries within the gas inventory database. These are 

identified in the gas inventory database as PriceType=3 purchase and sale 
entries (DBCR=0 or1). 

The recalculation of costs will only be allowed to occur when the gas month 
35 status has been set to the appropriate month 

Inputs: 

GasMonthx - Gas Month to calculate 
40 WhichPricex - 0=Nominations, 1 =Actualizations 

PKGx - either 0 for all or a specific package (deal) number 
EntityCIDx - owning company id 



History: 

06/30/1999 JAMIE Orignal Creation. 



03/22/2000 JAMIE Modified to move the Divie process to the main module. In addition, 
modified to handle the new routing table (LegDetail) and build routing records 
50 based on the routing rules within this table. 

05/24/2000 JAMIE Modified to be aware of entity and product types and services. In 
addition, modifications made to calculate based on new routing structure... 



55 V 

r 



* Declare all variables and cursors 

* that are needed by this process. 



•/ 

DECLARE ©zMessage VARCHAR(254) 
DECLARE ©zPackage INTEGER 
DECLARE ©zRecTID INTEGER 
65 DECLARE ©zDelTID INTEGER 

DECLARE ©zVolume DECIMAL(19,2) 
DECLARE ©zAmount DECIMAL(19,2) 
DECLARE ©zRate DECIMAL(19,8) 
DECLARE ©zLastDay DATETIME 

70 
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DECLARE @yTlD INTEGER 

DECLARE ©yGasDay DATETIME 
DECLARE @yDe!MID INTEGER 
DECLARE ©yRecMID INTEGER 
DECLARE @yLID INTEGER 
DECLARE ©yReceipt DECIMAL(19,2) 
DECLARE ©yFuelOrOther DECIMAL(1 9,2) 
DECLARE ©yDelivered DECIMAL(19,2) 
DECLARE ©yTransportationRate DECIMAL(19,8) 
DECLARE ©yGatheringRate DECIMAL(19,8) 
DECLARE ©yFuelPercent DECIMAL(19,8) 
DECLARE ©yPlantVolReduction DECIMAL(19,8) 
DECLARE @yKID INTEGER 
DECLARE ©yRMeterPipe VARCHAR(12) 
DECLARE ©yRMeterMeter VARCHAR(14) 
DECLARE ©yDMeterPipe VARCHAR(12) 
DECLARE ©yDMeterMeter VARCHAR(14) 
DECLARE @yCID VARCHAR(12) 
DECLARE ©yKProductID INTEGER 
DECLARE ©yKServicelD INTEGER 
DECLARE ©yPurchasePKG INTEGER 

r 



* First, intialize any existing volumes for 

* this month on the gas inventory table 

* to a zero. In addition, set the 

* appropriate volume amounts and price 

* amounts on the 'Engine' table to zeros. 



*/ 

EXECUTE uspJLastDay @GasMonthx,@zLastDay OUTPUT 

SELECT ©zMessage = 'PSPriceTranportAII, Initializing Gas Inventory and Engine Information.../ 
EXECUTE usp_Message @zMessage 

DECLARE GaslnvCursor CURSOR LOCAL STATIC FORWARD.ONLY FOR 
SELECT 

Gaslnv.TID 
FROM 

Gaslnv, 
K 

WHERE 

Gaslnv.GasMonth=@GasMonthx AND 
Gaslnv.PriceType=3 AND 
K.KID=Gaslnv.KID AND 
K.E nUtyC I D=@E ntity C I Dx 

OPEN GaslnvCursor 

FETCH NEXT FROM GaslnvCursor INTO @yTID 
BEGIN TRANSACTION 
WHILE @@FETCH_STATUS = 0 
BEGIN 

IF @WhichPricex=0 
BEGIN 

UPDATE 

GaslnvD 
SET 

Nom=0, 
EstAct=0 

WHERE 

TID=@yTID AND 

GasDay BETWEEN ©GasMonthx AND ©zLastDay 

UPDATE 

Engine 
SET 

Volume=0, 
Amount=0, 
PriceOrRateNom=0 

WHERE 

TID=@yTID 

END 

IF @WhichPricex=1 
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BEGIN 

UPDATE 

GaslnvD 
SET 

WHERE 

UPDATE 

Engine 
SET 

WHERE 



PipelineActuals=0 
TID=@yTID AND 

GasDay BETWEEN @GasMonthx AND ©zLastDay 



VolumeAct=0, 
AmountAct=0, 
PriceOrRateAct=0 



TID=@yTID 



END 

FETCH NEXT FROM GaslnvCursor INTO @yTID 

END 

SELECT @zMessage = 'PSPriceTranportAll, Finished initializing Gas Inventor/ and Engine Information.. 
EXECUTE usp_Message @zMessage 
COMMIT WORK 
CLOSE GaslnvCursor 
DEALLOCATE GaslnvCursor 

(L 

* Now loop through each of leg detail 

* records for the month for this entity 

* and determine appropriate transportation 

* rates. 
* 

* Gas Inventory (PriceType=3) records will 

* be created (along with package if needed). 
* 

* Engine records will also be created. 
*/ 

SELECT @zMessage = 'PSPriceTranportAll, Analyzing Routing (legdetail) cursor....' 
EXECUTE usp_Message ©zMessage 

DECLARE LegDetailCursor CURSOR LOCAL STATIC FORWARD_ONLY FOR 
SELECT 

LD.GasDay, 
LD.DelMID, 
LD.RecMID, 
LD.LID, 
LD.Receipt, 
LD.FuelOrOther, 
LD.Delivered, 
LD.TransportationRate, 
LD.GatheringRate, 
LD.FuelPercent, 
LD.PIantVolReduction, 
LD.PurchasePKG, 
' RMeter.PipeField, 
RMeter. Meter, 
DMeter.PipeFleld, 
DMeter. Meter, 
LegRef.KID 
FROM 

LegDetail AS LD, 
LegRef, 

Meter AS RMeter, 
Meter AS DMeter 



WHERE 



K.KID = Package.KID AND 



LegRef.UD=LD.LID AND 
RMeter.MlD=LD.RecMID AND 
DMeter.MID=LD.DelMID AND 

LD.PurchasePointTID IN (SELECT TID FROM Gaslnv.Package.K WHERE Package.PKG=Gaslnv.PKG AND 
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Gaslnv.GasMonth=@GasMonthx and Gaslnv.DBCR=0 

and Gaslnv.PriceType=1 and K£ntityCID=@EntityCIDx) AND 

LD.GasMonth=@GasMonthx AND 
LD.GasDay>=@GasMonthx AND 
LD.GasDay<=@zLastDay AND 
LD.NomOrActuals=@WhichPricex AND 
LD.LIDoO AND 

(LD.TransportationRateoO OR LD.GatheringRate<>0 OR LD.FuelPercent<>0 OR 

LD.PIantVolReduction<>0) 

ORDER BY 

LegRef.LID 

OPEN LegDetailCursor 

FETCH NEXT FROM LegDetailCursor INTO ©yGasDay.QyDelMID.gyRecMID.gyLID.OyReceipt^yFuelOrOther, 

@yDelivered ) @yTransportationRate,@yGatheringRate P @yFuelPercent,@yPlantVolReduction,@yPurchasePKG, 

©yRMeterPipe.gyRMeterMeter.gyDMeterPipe.QyDMeterMeter.QyKID 
WHILE @@FETCH_STATUS = 0 
BEGIN 

BEGIN TRANSACTION 

r 



* First check to see if a transportation 

* package has been setup for this 

* contract/company... If not, then set 

* it up... A commit is immediately 

* performed here in order to 'preserve' 

* the package information (and its 

* associated ID). 

7 

SELECT @yKProductlD=KProductlD,@yKServicelD=KServicelD FROM Package where PKG=@yPurchasePKG 
SELECT @yCID=CID FROM K WHERE KID = @yKID 

SELECT @zPackage=ISNULL((SELECT PKG FROM Package WHERE KID=@yKID AND 
PackageGasMonth=@GasMonthx AND 

KProductlD=@yKProductlD AND 

KServicelD=@yKServicelD)/') 

IF (@zPackage- ') OR (@zPackage IS NULL) 
BEGIN 

SELECT @zPackage=(SELECT max(PKG) FROM package) + 1 
INSERT 

INTO 

Package 

(PKG.StartDate^ndDate.DescriptionPackage.Create.KID.CID.PackageGasMonthPackageStatus.Package.CreateBy, 

LastUpdateBy,LastUpdateDate,KProductlD,KServicelD) 

VALUES 

(©zPackage.gGasMonthx.gzLastDay/TRANSPORT 

DEAL'.getdateO.gyKID.igyCID.igGasMonthx/Created'.user.nameO, 

user_name(),getdate(),@yKProductlD,@yKServicelD) 

END 

/* 



* At this point we know that a package 

* has been created AND we have the 

* package identifier. Now build the 

* Gaslnv records IF they do not already 

* exist for this package. By adding a 

* new inventory item the daily (GaslnvD) 

* records are automatically created for 
*each day of the month. 



7 

SELECT @zRecTID=ISNULL((SELECT TID FROM Gaslnv WHERE GasMonth=@GasMonthx AND 

PKG=@zPackage AND PriceType=3 AND KID=@yKID AND 

PipeField=@yRMeterPipe AND 

Meter=@yRMeterMeter AND PID=@yLID AND DBCR=0) ( 0) 

IF @zRecTID=0 
BEGIN 

INSERT 
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INTO 



10 



15 



20 



25 



Gaslnv 



AND 



(GasMonth,CID i PipeField,Meter 1 DBCR i KID l PID,PKG,StatPriceType l Gaslnv_UT, 

Nom.EstActGaslnvJJU.Gaslnv^MID.PipelineActuals) 

VALUES 

(@GasMonthx,@yCID,@yRMeterPipe l @yRMeterMeter ) 0 l @yKID,@yLID,@zPackage,1,3,getdate(), 

0,0,user_name(),@yRecMID,0) 
SELECT @zRecTID=ISNULL((SELECTTID FROM Gaslnv WHERE GasMonth=@GasMonthx 



PriceType=3 AND KID=@yKID AND PipeField=@yRMeterPipe AND 
PID=@yLID AND DBCR=0),0) 

END 



PKG=@zPackageAND 
Meter=@yRMeterMeter AND 



SELECT @zDelTID=ISNULL((SELECT TID FROM Gaslnv WHERE GasMonth=@GasMonthx AND PKG=@zPackage 

PriceType=3 AND KID=@yKID AND 
PID=@yLIDANDDBCR=1),0) 



AND 



PipeField=@yDMeterPipe AND Meter=@yDMeterMeter AND 



IF @zDelTID=0 

BEGIN 



INSERT 



INTO 



Gaslnv 



30 



35 



40 



(GasMonth.CID.PipeField.Meter.DBCR.KID.PID.PKG.StatPriceType.Gaslnv.UT, 

Nom,EstAct ( Gaslnv_UU,Gaslnv_MID p PipelineActuals) 

VALUES 

(@GasMonthx,@yCID,@yDMeterPipe l @y^ 

0,0 1 user_name(),@yDelMID 1 0) 
SELECT @zDelTID=ISNULL((SELECT TID FROM Gaslnv WHERE GasMonth=@GasMonthx 

AND PKG=@zPackage AND 

PriceType=3 AND KID=@yKID 

AND PipeField=@yDMeterPipe AND Meter=@yDMeterMeter AND 

PID=@yLID AND DBCR=1),0) 

END 



45 



50 



55 



60 
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* At this point the gas package and gas 

* inventory items have been determined 

* (created if needed). Now go and post 

* the volume to the GaslnvD table. 



V 

IF @WhichPricex=0 
BEGIN 



END 

IF @WhichPricex=1 
BEGIN 



UPDATE 



UPDATE 



UPDATE 



GaslnvD 
SET 

WHERE 



GaslnvD 
SET 

WHERE 



GaslnvD 
SET 



nom=(nom-HgyRecetpt) 

TID=@zRecTlD AND 
GasDay=@yGasDay 



nom=(nom-*@yDelivered) 

TID=@zDelTID AND 
GasDay=@yGasDay 
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PipelineActuals=(PipelineActuals-*@yReceipt) 

WHERE 

TID=@zRecTID AND 
GasDay=@yGasDay 

5 UPDATE 

GaslnvD 
SET 

PipelineActuals=(PipelineActuals+@yDelivered) 

WHERE 

10 TID=@zDelTID AND 

GasDay=@yGasDay 

END 

15 * Any transport costs here??? 

* (engine transaction ID is 3) 

*/ 

IF @yTransportationRate<>0 
20 BEGIN 

SELECT @zRate=@yTransportationRate 

SELECT @zVolume=@yReceipt 

SELECT @zAmount=ROUND((@zRate*@zVolume) ( 2) 

IF ISNULL((SELECT count(*) FROM Engine WHERE TID=@zRecTID AND 

*** 25 Effective=@GasMonthx AND STID=3),0) < 1 

^ BEGIN 

m IF@WhichPricex=0 

frt BEGIN 

% INSERT 

30 INTO 



35 



Engine 



(TID.Effective.STID.VolLevel.VolGroup.MMBtuMCF.Engine UT ( Engine_UU,Volume t Amount,PriceOrRateNom) 

VALUES 



(©zRecTID.QGasMonthx.S.O.QzPackage.l.getdatetl.user.namefl.gzVolume.gzAmountQzRate) 

END 

IF @WhichPricex=1 

BEGIN 

40 INSERT 

INTO 

Engine 

(TID,Effective,STID ( VolLevel t VolGroup ( MMBtuMCF ( Engine UT,Engine UU,VolumeAct P AmountAct,PriceOrRateAct) 
45 VALUES 

(©zRecTID.QGasMonthx.S.O.QzPackage.l.getdateO.user.namefJ.igzVolurne.igzAmountgzRate) 

END 

END 

50 ELSE 

BEGIN 

IF @WhichPricex=0 

BEGIN 
UPDATE 

55 Engine 

SET 

Volume=(Volume+@zVolume) ) 
Amount=(AmounWa)zAmount), 

60 PriceOi^ateNom=ROUND(((Amount+@zAmount)/(Volurne-H§zVolurne)),4) 

WHERE 

TID=@zRecTID AND 

Effective=@GasMonthx AND 

65 STID=3 

END 

IF @WhichPricex=1 
BEGIN 
UPDATE 

70 Engine 
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SET 



Vo!umeArt=(VolumeAct-*@zVolume), 
AmountAct=(AmountAct+@zAmount), 

PriceOrRateAct=ROUND(((AmountArt-^zAmount)/(VolumeAct-^zVolume)),4) 



WHERE 



Effective=@GasMonthx AND 



END 



TlD=@zRecTID AND 
STID=3 



END 



END 



* Any gathering costs here??? 

* (engine transaction ID is 4) 

*/ 

IF @yGatheringRate<>0 
BEGIN 

SELECT @zRate=@yGatheringRate 

SELECT @zVolume=@yReceipt 

SELECT @zAmount=ROUND((@zRate*@zVolume) ( 2) 

IF ISNULL((SELECT county FROM Engine WHERE TID=@zRecTID AND 

Effective=@GasMonthx AND STID=4) P 0) < 1 

BEGIN 

IF @WhichPricex=0 

BEGIN 
INSERT 

INTO 

Engine 

(TID^ffective.STID.VolLevel.VolGroup.MM 

VALUES 

(@zRecTID ( @GasMonthx,4,0,@zPackage,1 t getdate(),user name() P @zVolume,@zAmount,@zRate) 

END 

IF @WhichPricex=1 

BEGIN 
INSERT 

INTO 

Engine 

(TID.Effectwe.STID.VolLevel.VolGro 

VALUES 

(@zRecTlD,@GasMonthx,4 p 0 p @zPackage ) 1,getdate(),user_name(),@zVolume l @zArnount,@zRate) 

END 

END 

ELSE 

BEGIN 

IF @WhichPricex=0 

BEGIN 
UPDATE 

Engine 
SET 

Volume=(Volume+@zVolume), 
Amount=(Amount+@zAmount), 

Pric^OrRateNom=ROUND(((Amount->@zAmount)/(Volurne+@zVolume)) P 4) 

WHERE 

TID=@zRecTID AND 

Effective=@GasMonthx AND 

STID=4 

END 

IF @WhichPricex=1 
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BEGIN 
UPDATE 

Engine 
SET 



VolumeAd=(VolumeAcH§>zVolume), 
AmountAct=(AmountAct+@zAmount), 

PriceOrRateAct=ROUND(((AmountAd^zAmount)/(VolumeAct-^2Volume)) ( 4) 



WHERE 



Effective=@GasMonthx AND 



END 



TlD=@zRecTlD AND 
STID=4 



END 

END 



* Any fuel costs?? 

* (engine transaction ID is 5) 



V 

IF @yFuelPercent<>0 
BEGIN 

SELECT @zRate=@yFueIPercent 
SELECT @zVolume=@yReceipt*@zRate 

IF ISNULL((SELECT countf) FROM Engine WHERE TID=@zRecTID AND 

Effective=@GasMonthx AND STID=5),0) < 1 

BEGIN 

IF @WhichPricex=0 

BEGIN 
INSERT 

INTO 

Engine 

(TID.Effective.STID.VolLevel.VolGroup.MM 

VALUES 

(©zRecTID.QGasMonthx.S.O.QzPackage.l.getdateO.user nameO.QzVolume.O.QzRate) 

END 

IF @WhichPricex=1 

BEGIN 
INSERT 

INTO 

Engine 

(TID.Effective.STID.VolLevel.VolGroup.MMBtuM^ 

VALUES 

(©zRecTID^GasMonthx.S.O.tgzPackage.l.getdatefJ.useLnameO.QzVolume.O.QzRate) 

END 

END 

ELSE 

BEGIN 



IF @WhichPricex=0 

BEGIN 
UPDATE 



WHERE 



Effective=@GasMonthx AND 



Engine 
SET 

Volume=(Volume-K5)zVolume) 

TID=@zRecTID AND 

STID=5 



END 

IF @WhichPricex=1 
BEGIN 
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Engine 
SET 



VolumeAct=(VolumeAct+@zVolume) 



Effective=@GasMonthx AND 



END 



WHERE 



TID=@zRecTID AND 
STID=5 



END 



END 



* Any pvr?? 

* (engine transaction ID is 6) 
V 

IF @yPlantVo!Reduction<>0 
BEGIN 

SELECT @zRate=@yPlantVolReduction 
SELECT @zVolume=@yReceipt*@zRate 

IF ISNULL((SELECT count(*) FROM Engine WHERE TID=@zRecTID AND 

Effective=@GasMonthx AND STID=6),0) < 1 

BEGIN 

IF @WhichPricex=0 

BEGIN 
INSERT 

INTO 

Engine 

(TID.Effective.STID.VolLevel.VolGroup.MMBtuMCF.Engine.UT.Engine UU.Volume.Amount.PriceOrRateNom) 

VALUES 

(©zRecTID.QGasMonthx.e.O.tgzPackage.l.getdateO.user.nametl.gzVolume.O.gzRate) 

END 

IF @WhichPricex=1 

BEGIN 
INSERT 



INTO 



Engine 



(TID.Effective.STID.VolLevel.M^ 

VALUES 

(©zRecTID.gGasMonthx.e.O.QzPackage.l.getdatetJ.user.nametJ.gzVolume.O.QzRate) 

END 

END 

ELSE 

BEGIN 



IF @WhichPricex=0 



BEGIN 
UPDATE 



WHERE 



Effective=@GasMonthx AND 



END 

IF@WhichPricex=1 
BEGIN 
UPDATE 



Engine 
SET 

Volume=(Volume+@zVolume) 

TID=@zRecTID AND 

STID=6 



Engine 
SET 



VolumeAct=(VolumeAct*@zVolume) 
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WHERE 

TID=@zRecTID AND 

Effective=@GasMonthx AND 

STID=6 

END 

END 

END 

COMMIT WORK 

FETCH NEXT FROM LegDetailCursor INTO @yGasDay 1 @yDelMID J @yRecMID ( @yLID ( @yReceipt,@yFuelOrOther, 

@yDelivered,@yTransportationRate,@yGatheringRate,^^ 

@yRMeterPipe,@yRMeterMeter,@yDMeterPipe 1 @yDMeterMeter,@yKID 
END 

CLOSE LegDetailCursor 

DEALLOCATE LegDetailCursor 

SELECT @zMessage = 'PSPriceTranportAII, Finished..,.' 

EXECUTE usp.Message @zMessage 

END 



GO 

SET QUOTEDJDENTIFIER OFF SET ANSI.NULLS ON 
GO 



SET QUOTEDJDENTIFIER OFF SET ANSI.NULLS ON 
GO 

CREATE PROCEDURE usp_PSPriceWASPCalc( 

©GasMonthx DATETIME, 
©WhichPricex INTEGER, 
@EntityCIDxVARCHAR(12) 
) 

AS 

BEGIN 

r ^ ^^^ 
Name: usp_PSPriceWaspCa!c 

Description: This is the main process for calculating the WASP price information for 
a particular gas month and type of price (nom's or pipeline actuals). The end result 
of this process is to post updated price amounts within the engine. The WASP calculation 
has also been modified to perform the calculations pooled by entity (passed to this 
routine), within entity by product (Oii/Gas/Liguids) and service (marketing/passth rough/etc). 

Inputs: 

GasMonthx (Gas Month to calculate), 

WhichPricex (0=Nominations, ^Actualizations) 

EntityCIDx (which company is being calculated (owner company)) 

History: 

06/22/99 JAMIE Original creation 

07/22/99 JAMIE Include 3rd party deals within the 
calcualtion process. They WILL NOT BE included within the WASP calculations 
and will be treated the same as "Dedicated" (sanctioned sales) deals. This 
will ensure they are not affecting any other pricing component, 

05/01/00 JAMIE Modifications to utilize the new routing structure as part of the 
calculation. A check is made to see if any 'routing' entries are made to the new 
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structures (for the month). If so, then this routine will invoke the new routines. 
Otherwise, the old routines are invoked. 

05/24/2000 JAMIE Modifications to add the EntityCIDx component to the calculation (passed 
to this routine by the calling program). In addition, modifications were made to calculate 
all WASP pricing within each unique product and service. 

08/25/2000 JAMIE Modified to remove all of the old routing routines. 



7 

r 

HHr 

* Declare all variables and cursors 

* that are needed by this process. 
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DECLARE ©zMessage VARCHAR(254) 
DECLARE ©yKProductID INTEGER 
DECLARE ©yKProductName VARCHAR(SO) 

DECLARE ©yKServicelD INTEGER 
DECLARE ©yKServiceName VARCHAR(50) 

DECLARE ProductTypesCursor CURSOR LOCAL STATIC FORWARD.ONLY FOR 
SELECT 

Processing CodelD, 

ShortDescription 

FROM 

SEProcessingCodes WHERE CodeType='CONTRPRODS' 

ORDER BY 

ProcessingCodelD 

SELECT ©zMessage = 'PSPriceWASPCalc, Running for Entity '+©EntityCIDx+\..' 
EXECUTE usp.Message ©zMessage 

r 



* Outermost loop is on product type... 



7 

OPEN ProductTypesCursor 

FETCH NEXT FROM ProductTypesCursor INTO @yKProductlD,@yKProductName 
WHILE @@FETCH_STATUS = 0 
BEGIN 

SELECT ©zMessage = 'PSPriceWASPCalc, Running for Product , -K§yKProductName+'../ 
EXECUTE usp_Message ©zMessage 
r 

* Next loop is on service type... 
7 

DECLARE ServiceTypesCursor CURSOR LOCAL STATIC FORWARD_ONLY FOR 
SELECT 

ProcessingCodelD, 

ShortDescription 

FROM 

SEProcessingCodes WHERE CodeType='CONTRSRVS' 

ORDER BY 

ProcessingCodelD 

OPEN ServiceTypesCursor 

FETCH NEXT FROM ServiceTypesCursor INTO @yKServicelD,@yKServiceName 
WHILE @@FETCH_STATUS = 0 
BEGIN 

BEGIN TRANSACTION 

SELECT ©zMessage = 'PSPriceWASPCalc, Running for Service '-K£§yKServiceName^ 
EXECUTE usp_Message ©zMessage 

r 



* Now populate the waspresolvedrouting 

* tables with all sales and transport 
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* totals that were linked to purchases 

* within the route process. 



V 

EXECUTE usp_PSPriceWASPCalcSalesN 
©GasMonthx^WhichPricex.QEntityCIDx.QyKProductlD.gyKServicelD 

COMMIT WORK 

FETCH NEXT FROM ServiceTypesCursor INTO @yKServicelD,@yKServiceName 

END 

CLOSE ServiceTypesCursor 
DEALLOCATE ServiceTypesCursor 

FETCH NEXT FROM ProductTypesCursor INTO @yKProductlD,@yKProductName 

END 

CLOSE ProductTypesCursor 
DEALLOCATE ProductTypesCursor 

r 



* Finished. A later routine will take 

* the well prices to the actual engine 

* table (PSPriceAII for Purchases). A 

* commit takes place right here just to 

* make sure we limit our recovery window 

* if problems later. Also, don't want 

* to hold locks for an extended amount 

* of time. 



7 

SELECT ©zMessage = 'PSPriceWASPCalc, Finished with Entity ' +@E ntity C I Dx v . . 

EXECUTE usp_Message ©zMessage 

END 



GO 

SET QUOTEDJDENTIFIER OFF SET ANSl.NULLS ON 
GO 

SET QUOTEDJDENTIFIER OFF SET ANSLNULLS ON 
GO 

CREATE PROCEDURE usp_PSPriceWASPCalcResolveDriver( 

©GasMonthx DATETIME, 
©WhichPricex INTEGER, 
@EntityCIDxVARCHAR(12), 
©IncludelnWaspx VARCHAR(10) 
) 

AS 

BEGIN 
I* 



Name: usp.PSPriceWaspCalcResolveDriver 

Description: This is the main process that controls the 'walking back' (resolving) 
of sales amounts back to their respective purchase deals. 

Inputs: 

GasMonthx (Gas Month to calculate), 

WhichPricex (^Nominations, ^Actualizations) 

EntityCIDx (which company is being calculated (owner company)) 

IncludelnWaspx ('Common' /None' or 'Dedicated') 

History: 

07/28/2000 JAMIE Original creation 



7 
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* Declare all variables and cursors 

* that are needed by this process. 



*/ 

DECLARE ©zMessage VARCHAR(254) 
DECLARE ©yKProductID INTEGER 
DECLARE ©yKProductName VARCHAR(50) 

DECLARE @yKServicelD INTEGER 
DECLARE ©yKServiceName VARCHAR(50) 

DECLARE ProductTypesCursor CURSOR LOCAL STATIC FORWARD_ONLY FOR 
SELECT 

ProcessingCodelD, 

ShortDescription 

FROM 

SEProcessingCodes 

WHERE 

CodeType=*CONTRPRODS' 

ORDER BY 

ProcessingCodelD 

SELECT ©zMessage = 'PSPriceWASPCalcResloveDriver, Running for Entity , +@EntityCIDx+' 1 Pool '+@lncludelnWaspx+\./ 
EXECUTE usp.Message @zMessage 

r lllLl l , l lL 

* Outermost loop is on product type... 

7 

OPEN ProductTypesCursor 

FETCH NEXT FROM ProductTypesCursor INTO @yKProductlD,@yKProductName 
WHILE @@FETCH_STATUS = 0 
BEGIN 

SELECT @zMessage = 'PSPriceWASPCalcResloveDriver, Running for Product , 4@yKProductName+'...' 
EXECUTE usp Message ©zMessage 

r 



* Next loop is on service type... 
*/ 

DECLARE ServiceTypesCursor CURSOR LOCAL STATIC FORWARD.ONLY FOR 
SELECT 

ProcessingCodelD, 

ShortDescription 

FROM 

SEProcessingCodes 

WHERE 

CodeType='CONTRSRVS' 

ORDER BY 

ProcessingCodelD 

OPEN ServiceTypesCursor 

FETCH NEXT FROM ServiceTypesCursor INTO @yKServicelD,@yKServiceName 
WHILE @@FETCH_STATUS = 0 
BEGIN 

BEGIN TRANSACTION 

SELECT @zMessage = 'PSPriceWASPCalcResloveDriver, Running for Service 

'+@yKServiceName+\..' 

EXECUTE usp_Message @zMessage 
EXECUTE usp.PSPriceWASPCalcResolveN 
@GasMonthx,@WhichPricex,@EntityCIDx,@yKProductlD p @yKServicelD,@lncludelnWaspx 

COMMIT WORK 

FETCH NEXT FROM ServiceTypesCursor INTO @yKServicelD,@yKServiceName 

END 

CLOSE ServiceTypesCursor 
DEALLOCATE ServiceTypesCursor 

FETCH NEXT FROM ProductTypesCursor INTO @yKProductlD,@yKProductName 

END 

CLOSE ProductTypesCursor 
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DEALLOCATE ProductTypesCursor 

SELECT @zMessage = 'PSPriceWASPCalcResofveDriver, Finished with Entity '-*@EntityCIDx+',Pool , -K5)lnclude]nWaspx+ l . i .' 

EXECUTE usp_Message @zMessage 

END 



GO 

SET QUOTED IDENTIFIER OFF SET ANSLNULLS ON 
GO 

SET QUOTED IDENTIFIER ON SET ANSLNULLS ON 
GO 

CREATE PROCEDURE usp_PSPriceWASPCalcResolveN( 

@GasMonthx DATETIME, 
©WhichPricex INTEGER, 
@EntityCIDxVARCHAR(12), 
©KProductlDx INTEGER, 
@KServicelDx INTEGER, 
@lncludelnWaspx VARCHAR(10) 
) 

AS 

BEGIN 
/* 



Name: usp.PSPriceWASPCalcResolveN 

Description: This particular stored procedure is responsible for looping through and 
chasing all volumes back from purchase points back to the respective meter locations 
that originally contained the purchase volumes. 

History: 

05/01/2000 JAMIE Original Creation. 

05/24/2000 JAMIE Modified to include the entity, product and service. 

07/28/2000 JAMIE Modified to include the InciudelnWaspx parameter so that 
the calculations can be run in a specified WASP order... 

08/17/2000 JAMIE Removed the call to PSWASPCalcPostPurchaseN. This 
was done based on all wasp calculation entries being setup in the 
WASPResolvedRouting table. 



r 



* Declare all variables and cursors 

* that are needed by this process. 



7 

DECLARE ©zMessage VARCHAR(254) 

SELECT ©zMessage = 'PSPriceWASPCalcResolveN Has Started for pool '+@lncludelnWaspx+\./ 
EXECUTE usp_Message @zMessage 

!L™ 

* Now invoke the routine that will chase 

* the volumes, prices and amounts back to 

* the purchase points. 



7 

SELECT ©zMessage = 'PSPriceWASPCalcResolveN, Tracing back all gas (resolving sales)...' 
EXECUTE usp_Message @zMessage 

EXECUTE usp.PSPriceWASPCalcResolveSalesN ©GasMonthx.gWhichPricex.gEntityCIDx^KProductlDx.gKServicelDx.glncludelnWaspx 

r 
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* Time to leave,.. 



V 

SELECT @zMessage = 'PSPriceWASPCalcResolveN Has Completed for Pool '-HglncludelnWaspx* 

EXECUTE uspjvlessage @zMessage 

END 



10 GO 

SET QUOTEDJDENTIFIER OFF SET ANSI.NULLS ON 
GO 

SET QUOTEDJDENTIFIER OFF SET ANSI.NULLS ON 
15 GO 



id 



20 



25 
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CREATE PROCEDURE usp_PSPriceWASPCalcResolveSalesN( 



AS 

BEGIN 

r 



©GasMonthx DATETIME, 
©WhichPricex INTEGER, 
©EntityCIDx VARCHAR(12), 
©KProductlDx INTEGER, 
©KServicelDx INTEGER, 
@lncludelnWaspx VARCHAR(10) 
) 



Name: usp.PSPriceWASPCalcResolveSales 

Description: This particular stored procedure will loop through (iteratively) all of 
the sales meter records within the WASPResolvedRouting table (type 'S' records) and 
distribute their respective volumes, amounts and prices back to the purchase points 
(wieghted). 

All volumes should match here since the routing process routes purchase deals directly 
to sales deals AND the WASPResolvedRouting table was built on explicit volumes and 
links found in the Leg Detail (main routing) table. 

Inputs: 

GasMonthx - Gas Month 
WhichPricex-0=Nominations, 1=Actuals 
EntityCIDx - owning company 
KProductlDx - product id (oil, gas, liquids, etc.) 
KServicelDx - service id (marketing, passthrough, etc.) 
IncludelnWaspx - ('Common' or 'None' or 'Dedicated') 

History: 

05/01/2000 JAMIE Original Creation. 

07/20/2000 JAMIE Modified in order to capture and save resolved total amounts 
along with the resolved volume amounts. This was required in order to correct a 
calculation problem. 

07/28/2000 JAMIE Modified to take into consideration which WASP pool is currently 
being resolved. 

12/05/2000 JAMIE Modified to ensure that the receipt amount will not be exceeded 
when determining the volume to use. This situation only arose when certain 
unresolved records were ordered a certain way (during the resolution ritual). 
Confusing, I know, but that is the best I can do... The field zTempLeft contains 
this informaion 



70 



* Declare all variables and cursors 
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* that are needed by this process. 



7 

DECLARE @zTempLeft DECIMAL(19,2) 
5 DECLARE ©zRound INTEGER 

DECLARE ©zMessage VARCHAR(254) 
DECLARE ©zAnyUpdates VARCHAR(1) 
DECLARE @zResolvedReceipt DECIMAL(19,2) 
DECLARE ©zResolvedReceiptAmt DECIMAL(19,2) 
1 0 DECLARE ©zResolvedDelivered DECIMAL(19,2) 

DECLARE ©zResolvedDeliveredAmt DECIMAL(19,2) 
DECLARE @zReceipleftDECIMAL(19 P 2) 
DECLARE ©zReceiptAmleft DECIMAL(19,2) 
DECLARE ©zPercentToApply DECIMAL(19,6) 
1 5 DECLARE ©zSumDelivered DECIMAL(19,2) 

DECLARE ©zPercentReceipt DECIMAL{19,6) 
DECLARE ©zUseVolume DECIMAL(19,2) 
DECLARE ©zUseAmount DECIMAL(19,2) 
DECLARE ©zAmount DECIMAL(19,2) 
20 DECLARE ©zNewAmount DECIMAL(19,2) 

DECLARE ©zNewPrice DECIMAL(19,6) 
DECLARE ©zTempVolume DECIMAL(19,2) 
DECLARE @zTempAmountDECIMAL(19 P 2) 
DECLARE ©zVolumeDispersed DECIMAL(19,2) 
25 DECLARE ©zAmountDispersed DECIMAL(19,2) 

DECLARE ©zDifference DECIMAL(19,2) 
tQ DECLARE ©zResolvedlndicator VARCHAR(1 ) 

DECLARE ©zLinkUpdate VARCHAR(1) 
^ DECLARE ©zDeliveredLeft DECIMAL(19 ( 2) 

*9 30 

j n DECLARE ©yDelMID INTEGER 

~ DECLARE ©yRecMID INTEGER 

^ DECLARE @yReceipt DECIMAL(1 9,2) 

Ms DECLARE @yFuelOrOther DECIMAL(19,2) 

L. 35 DECLARE ©yDelivered DECIMAL(19,2) 

r '" DECLARE ©yTransportAmount DECIMAL(19,2) 

2 DECLARE ©yGatheringAmount DECIMAL(19,2) 

U= DECLARE ©yAmount DEC IMAL( 19,2) 

n • DECLARE ©yDedicatedPurchasePKG INTEGER 

*™ 40 DECLARE @yPriceDECIMAL(19,6) 

yj DECLARE ©yResolvedReceipt DECIMAL(1 9,2) 

U, DECLARE ©ylncludelnWasp VARCHAR(IO) 

» DECLARE ©yResolvedDelivered DECIMAL(19,2) 

M DECLARE ©yResolvedID INTEGER 

U 45 DECLARE ©yResolvedReceiptAmt DECIMAL(19,2) 

DECLARE ©yResolvedDeliveredAmt DECIMAL(19,2) 

DECLARE ©IDelMID INTEGER 
DECLARE ©IRecMID INTEGER 

50 DECLARE ©Receipt DECIMAL(19,2) 

DECLARE @IFuelOrOther DECIMAL(19,2) 
DECLARE ©Delivered DECIMAL(19,2) 
DECLARE ©ITransportAmount DECIMAL(19,2) 
DECLARE ©IGatheringAmount DECIMAL(19,2) 

55 DECLARE ©[Amount DECIMAL(19,2) 

DECLARE ©IDedicatedPurchasePKG INTEGER 
DECLARE ©IPrice DECIMAL(15,6) 
DECLARE ©IResolvedReceipt DECIMAL(19,2) 
DECLARE ©llncludelnWasp VARCHAR(IO) 

60 DECLARE ©IResolvedDelivered DECIMAL(1 9,2) 

DECLARE ©IResolvedID INTEGER 
DECLARE ©IResolvedReceiptAmt DECIMAL(19,2) 
DECLARE ©IResolvedDeliveredAmt DECIMAL(19,2) 

65 r 



* This loop will iterate until no more 

* gas can be distributed to various 

* sales meters within the 

70 * WaspResolvedRouting table. 
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7 

SELECT ©zRound = ISNULL((SELECT TypeLimit FROM SEProcessingCodes WHERE ProcessingCodelD = @KProductlDx),0) 
SELECT ©zMessage = 'PSPriceWASPCalcResofveSalesN, starting iterative process../ 
EXECUTE usp.Message ©zMessage 
SalesMeterlterationLoop: 
BEGIN 

SELECT @zAnyUpdates='N' 

DECLARE WASPResolvedSalesCursor CURSOR LOCAL DYNAMIC FORWARD.ONLY FOR 
SELECT 

DelMID, 

RecMID, 

Receipt, 

FuelOrOther, 

Delivered, 

TransportAmount, 

GatheringAmount, 

Amount, 

DedicatedPurchasePKG, 
Price, 

ResolvedReceipt, 

IncludelnWasp, 

ResolvedDelivered, 

ResolvedID, 

ResolvedReceiptAmt, 

ResolvedDeliveredAmt 

FROM 

WASPResolvedRouting 

WHERE 

(GasMonth=@GasMonthx AND 
NomOrActual=@WhichPricex AND 
lncludelnWasp=@lncludelnWaspx AND 
ResolvedlndicatoroT AND 
Resolved ReceiptoReceipt AND 
ResolvedTypeo'P 1 AND 
Amount<>0 AND 
Price<>0 AND 
Delivered<>0 AND 
EntityCID=@EntityCIDxAND 
KProductlD=@KProductlDx AND 
KServicelD=@KServicelDx) 

ORDER BY 

IncludelnWasp, 

DedicatedPurchasePKG, 

DelMID 

OPEN WASPResolvedSalesCursor 

FETCH NEXT FROM WASPResolvedSalesCursor INTO ©yDelMID, 
@yRecMID,@yReceipt,@yFueiOrOther,@yDe^^ 

KG, 

@yPrice,@yResolvedReceipt,@ylncludelnWasp,@yResolved Delivered, ©yResolved ID, 

@yResolvedReceiptAmt@yResolvedDeliveredAmt 

WHILE @@FETCH_STATUS = 0 
BEGIN 

* Loop through each of the legs that 

* have the delivery meter the same as 

* the receipt meter for the given 

* month and class... 

7 

SELECT @zVolumeDispersed=0 
SELECT @zAmountDispersed=0 
SELECT @zLinkUpdate='N' 

DECLARE WASPResolvedLinkCursor CURSOR LOCAL DYNAMIC FORWARD.ONLY FOR 
SELECT 

DelMID, 
RecMID, 
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Receipt, 

FuelOrOther, 

Delivered, 

TransportAmount, 

GatheringAmount, 

Amount 

DedicatedPurchasePKG, 
Price, 

ResolvedReceipt, 

IncludelnWasp, 

ResolvedDelivered, 

ResolvedID, 

ResolvedReceiptAmt, 

ResolvedDeliveredAmt 

FROM 

WASPResolvedRouting 

WHERE 

(GasMonth=@GasMonthx AND 
NomOrActual=@WhichPricex AND 
lncludelnWasp=@ylncludelnWasp AND 
DedicatedPurchasePKG=@yDedicatedPurchasePKGAND 
DelMID=@yRecMID AND 
ResolvedlD<>@yResolvedlD AND 
EntityCID=@EntityCIDxAND 
KProductlD=@KProductlDx AND 
KServicelD=@KServicelDx AND 
ResolvedTypeo'S' AND 
ResolvedDelivered<De!ivered) 

OPEN WASPResolvedLinkCursor 
FETCH NEXT FROM WASPResolvedLinkCursor INTO @IDelMID, 

@IRecMID,@IRecEipt@IFuelOrOther,@^^ 

@IPrice,@IResolvedReceipt,@llncludelnWasp 1 @!ResolvedDelivered,@IResolvedlD, 

@IResolvedReceiptAmt,@IResolvedDeliveredAmt 

WHILE @@FETCH_STATUS = 0 
BEGIN 

r ^ 

* Determine the total volume of gas 

* where this gas came from (based on 

* delivery meterid being equal to 

* the receipt meter id and all WASP 

* pool and dedicated purchase package 

* information being identical). 

* The zUseVolume field contains the 

* amount of volume from the delivery 

* meter to apply backward. 

* The zUseAmount field contains the 

* dollar amount from the delivery meter 

* that should be applied backward. 
* 

* The zPercentToApply field contains the 

* volume weighted percentage to use. 



*/ 

SELECT @zResolvedReceipt=@yResolvedReceipt 
SELECT @zResolvedReceiptAmt=@yResolvedReceiptAmt 
SELECT @zPercentReceipt=1 

I* Determine total receipt volume available to apply*/ 
/* This is based on percentage of delivered that may have*/ 
/* already been applied. In addition, determine the*/ 
I* amount that is available...*/ 

IF (@yDelivered<>0) AND (@yResolvedDelivered<>0) AND 

(@yDelivered>@yResolvedDelivered) 

BEGIN 
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SELECT 

@2PercentReceipt=(@yResolvedDelivered/@yDelivered) 

END 



@zPercentReceipt),@zRound); 



RecMIDoDelMID 



WASPResolvedRouting 



/* Incorporated this logic to ensure that no more than 7 
1* the original receipt can be sent back to previous 7 
r meter... 12/05/2000*/ 

SELECT @zReceipieft=ROUNO((@yReceipt*@zPercentReceipt),@zRound) 
SELECT @zTempLeft=(@yReceipt - @yResolvedReceipt) 
SELECT @zTempLeft=Round((@zTempLeft* 

IF ©zTempLeft < @zReceiptLeft 
BEGIN 

SELECT @zReceipleft=@zTempLeft 

END 

SELECT @zReceiptAmtLeft=ROUND((@yAmount-@yResolvedReceiptAmt) ( 2) 
/* Determine percentage of the volumes and amounts to apply... and 



SELECT @zPercentToApply=1 

SELECT @zSumDelivered=ISNULL((SELECT SUM(Delivered) FROM 



WHERE GasMonth=@GasMonthx 
AND NomOrActual=@WhichPricex AND lncludelnWasp=@ylncludelnWasp AND 

DedicatedPurchasePKG=@yDedicatedPurchasePKG AND DelMid=@yRecMID AND ResolvedTypeo'S' AND 

EntityCID=@EntityCIDx AND 

KProductlD=@KProductlDx AND KServicelD=@KServicelDx),0) 

IF (@zSumDelivered<>0) AND (@IDelivered<>0) 
BEGIN 
SELECT 

@zPercentToApply=ROUND((@IDelivered/@zSumDelivered),6) 

END 

ELSE 

BEGIN 

SELECT @zPercentToApply=0 
END 

/* Calculate volume to apply backwards for this particular leg...*/ 

SELECT @zUseVolume=ROUND((@zReceiptLeft*@zPercentToApply),@zRound) 
SELECT @zDeliveredLeft=@IDelivered-@IResolvedDe!ivered 
IF @zUseVolume>@zDeliveredLeft 
BEGIN 

SELECT @zUseVolume=@zDeliveredLeft 
END 

SELECT @zResolvedReceipt=@zResolvedReceipt-^@zUseVolume 
SELECT @zVolumeDispersed=@zVolumeDispersed+@zUseVolume 

r Calculate dollar amount to apply backwards for this particular leg...*/ 

SELECT @zUseAmount=ROUND((@zReceiptAmtLeft*@zPercentToApply),2) 
SELECT @zResolvedReceiptAmt=@zResolvedReceiptAmt+@zUseAmount 
SELECT @zAmountDispersed=@zAmountDispersed+@zUseAmount 
/* 

* Now update the meter feeding 

* this delivery point with the 

* information just posted... 
* 

* The amount is calculated based 

* on the previous value plus 

* the amount being posted from 

* the delivery meter. The 

* price is derived based on 

* receipt volume into the amount. 
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* Since we are not forcing the pipes 

* to balance then calculate the price 

* based solely on the volume resolved 

* on delivery. 

7 

IF (@zllseVolume>0) AND (@zUseAmount<>0) 
BEGIN 

SELECT 



@zResolvedDelivered=@IResolvedDelivered-^@zUseVolume 

@zResolvedDeliveredAmt=@IResolvedDeliveredAmt-*@zUseAmount 

@zNewAmount=ROUND((@IAmount-t@zUseAmount) p 2) 

@zNewPrice=ROUND((@zNewAmount/@IReceipt),4) 
@zNewPrice=0 



Resolvedlndicator='N', 
ResolvedDelivered=@zResolvedDelivered, 
ResolvedDeliveredAmt=@zResolvedDeliveredAmt, 
Amount=@zNewAmount l 

ResolvedlD=@IResolvedlD 



SELECT 
SELECT 

IF (@zResolvedDeliveredAmt<>0) AND (@IReceipt<>0) 
BEGIN 

SELECT 



ELSE 



UPDATE 



END 
BEGIN 

END 



SELECT 



WASPResolvedRouting 
SET 



WHERE 



Price=@zNewPrice 



END 



SELECT @zAnyUpdates=Y 
SELECT @zLinkUpdate=T 



FETCH NEXT FROM WASPResolvedLinkCursor INTO ©IDelMID, 

@lRecMID p @IReceipt,@IFuelOrOther p @IDelivered p @ITransportAmount,@IGatheri 

@IPrice,@IResolvedReceipt,@llncludelnWasp,@IResolvedDelivered p @lResolvedlD, 

@IResolvedReceiptAmt,@IResolved Delivered Amt 

END 

CLOSE WASPResolvedLinkCursor 
DEALLOCATE WASPResolvedLinkCursor 

r 



* After looping through all of the 

* meters that can possible associate 

* with this sale, go ahead and update 

* the original sales meter information 

* to reflect the total volume 

* passed on to subsequent meters, 
♦a******************************* 



7 

IF @zLinkUpdate=T 
BEGIN 



UPDATE 



WASPResolvedRouting 
SET 

ResolvedReceipt=ResolvedReceipW§zVolumeDispersed, 



70 



ResolvedReceiptAmt=ResolvedReceiptAmt*@zAmountDispersed, 
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Resolvedlndicator=Y 

WHERE 

ResolvedlD=@yResolvedlD 

END 

FETCH NEXT FROM WASPResolvedSalesCursor INTO ©yDelMID, 
@yRecMID,@yReceipt,@yFuelOrOther p @^^ 

KG, 

@yPrice,@yResolvedReceipt,@ylncludelnWasp p @yResolved Delivered, ©yResolved ID, 

@yResolvedReceiptAmt ( @yResolved Delivered Amt 
END 

CLOSE WASPResolvedSalesCursor 
DEALLOCATE WASPResolvedSalesCursor 
I* 

* If no more volume was chased backward 

* then get out of the iterative loop. 

* At this point all volumes have been 

* sent back to all meters and weighted 

* costs should be available at each. 

*/ 

IF @zAnyUpdates<>'N' 
BEGIN 

GOTO SalesMeterlterationLoop 

END 

END 

END 



GO 

SET QUOTEDJDENTIFIER OFF SET ANSI NULLS ON 
GO 

SET QUOTEDJDENTIFIER OFF SET ANSI_NULLS ON 
GO 

CREATE PROCEDURE usp PSPriceWASPCalcSalesN( 

©GasMonthx DATETIME, 
©WhichPricex INTEGER, 
©EntityCIDx VARCHAR(12), 
©KProductlDx INTEGER, 
©KServicelDx INTEGER 
) 

AS 

BEGIN 

r luUAitlil AtlA1Alilli ^^^^ 

Name: usp.PSPriceWASPCalcSalesN 

Description: This process will build all of the meters within the 
WASPResolvedRouting table for all of the deals within the gas month. Only 
those meters that had actual transport volume will be moved. A 
different routine will iterate through the volumes posted here in order 
to calculate all of the prices. 

Inputs: 

GasMonthx - Gas Month 
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WhichPricex - 0=Nominations, 1=Actuals 
EntityCIDx - Entity being calculated (owning company) 
KProductlDx - Product type being calculated. 
KServicelDx - Service type being calculated. 

5 

History: 



05/02/2000 JAMIE Original Creation. 



1 0 05/24/2000 JAMIE Modified to add the Entity, product and service types to be 

parameters to this procedure. This will ensure that gas, oil, etc amongst the 
various types of companies (entities) being serviced do not get intermixed. 

07/20/2000 JAMIE Modified in order to initialize new resolved amount fields for 
1 5 all records that get added to the WASPResolvedRouting table. 

08/18/2000 JAMIE Modified to go ahead and put the actual purchase point 
items on the table to include them in the calculations. At this point the 
WASPResolvedRouting table will contain ALL entries (see Type' field on the 
20 database). Purchase points thru Sales points. 

10/03/2000 JAMIE Modified to incorporate the 'Other Cost* amount totals 
into the Resolved table total calculation. 

fc=f 25 01/09/2000 JAMIE For consistency. Modified the rounding (on the prices 

*jQ to two decimal places (for all months previous to December 2000). 

ill 30 r 



60 



* Declare all variables and cursors 

* that are needed by this process. 



35 V 

' DECLARE ©zMessage VARCHAR(254) 

M= DECLARE @zlncludelnWasp VARCHAR(10) 

n i DECLARE ©zVolume DECIMAL(1 9,2) 

; ~ DECLARE @zType VARCHAR(1) 

%M 40 DECLARE @zPriceDECIMAL(19,6) 

M= DECLARE ©zAmount DECIMAL(19,2) 

^ DECLARE ©zOtherCostAmount DECIMAL(19,2) 

^ DECLARE ©zDedicatedPurchasePKG INTEGER 

N« DECLARE ©zGatheringAmount DECIMAL(19,2) 

45 DECLARE ©zTransportationAmount DECIMAL(1 5,2) 

DECLARE ©zAmountWithCosts DECIMAL(19,2) 
DECLARE ©zLastDay DATETIME 
DECLARE ©zPrevSalePKG INTEGER 
DECLARE ©zPrevSaleMID INTEGER 

50 

DECLARE ©yPurchasePKG INTEGER 
DECLARE ©yRecMID INTEGER 
DECLARE ©yDelMID INTEGER 
DECLARE ©ySalesPKG INTEGER 
55 DECLARE ©yReceipt DECIMAL(19,2) 

DECLARE ©yLDIDPrev INTEGER 
DECLARE ©yGasDay DATETIME 
DECLARE ©yPurchasePointTID INTEGER 
DECLARE @yStep INTEGER 



DECLARE ©xPriceOrRateNom DECIMAL(19,6) 
DECLARE @xPriceOrRateActDEClMAL(19,6) 



DECLARE ©qPurchasePKG INTEGER 

65 DECLARE @qLID INTEGER 

DECLARE ©qRecMID INTEGER 
DECLARE ©qDelMID INTEGER 
DECLARE ©qReceipt DECIMAL(19,2) 
DECLARE ©qDelivered DECIMAL(19,2) 

70 DECLARE @qFuelOrOther DECIMAL(19,2) 
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DECLARE @qTransport DECIMAL) 19,2) 
DECLARE @qGathering DECIMAL(19,2) 



SELECT ©zMessage = 'PSPriceWASPCalcSalesN Has Started...' 
EXECUTE usp_Message @zMessage 

r 



* Delete any pre-existing resolved entries 

* that may exist in the database... These 

* records are the ones related to the 

* entity, product and service tyeps. 



*/ 

SELECT ©zMessage = 'PSPriceWASPCalcSalesN, Deleting existing entries off WASPResolvedRouting...' 

EXECUTE usp.Message @zMessage 

DELETE 

FROM 

WASPResolvedRouting 

WHERE 

GasMonth=@GasMonthx AND 
NomOrActual=@WhichPricex AND 
EntityCID=@EntityCIDxAND 
KProductlD=@KProductlDx AND 
KServicelD=@KServicelDx 

SELECT ©zMessage = 'PSPriceWASPCalcSalesN, Finished deleting existing entries off WASPResolvedRouting...' 
EXECUTE usp_Message @zMessage 
r 

* Initially loop through the sales links 

* found on the legdetail table (high level 

* loop)... Only looping through those 

* items that are associated with this 

* entity and product/service type. 



*/ 

SELECT @zPrevSalePKG=0 
SELECT @zPrevSaleMID=0 

EXECUTE uspJLastDay @GasMonthx,@zLastDay OUTPUT 
DECLARE LegDetailSaleCursor CURSOR LOCAL STATIC FORWARD.ONLY FOR 
SELECT 

PurchasePKG, 

RecMID, 

DelMID, 

SalesPKG, 

Receipt, 

LDIDPrev, 

GasDay, 

PurchasePointTID, 

Step 

FROM 

Leg Detail 

WHERE 

LegDetail.PurchasePointTID IN (SELECT DISTINCT TID FROM Gaslnv, Package, K WHERE 
Gaslnv.PKG=Package.PKG AND k.kid = Package.KID AND Gaslnv.GasMonth=@GasMonthx AND Gaslnv.DBCR=0 AND Gaslnv.PriceType=1 
and Package.KProductID = ©KProductlDx and Package.KServicelD = ©KServicelDx AND K.EntityCID = ©EntityCIDx) AND 

LegDetail.GasDay>=@GasMonthx AND 

LegDetail.GasDay<=@zLastDay AND 

LegDetail.GasMonth=@GasMonthx AND 

LegDetail.NomOrActuals=@WhichPricex AND 

LegDetail.LID=0 AND 

LegDetail.PurchasePKG>0 AND 

LegDetail.SalesPKG>0 

ORDER BY 

LegDetail.SalesPKG, 
LegDetail.RecMID, 
LegDetail.PurchasePointTID, 
Leg Detail. GasDay, 
LegDetatl.PurchasePKG 
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SELECT @zMessage = 'PSPriceWASPCalcSalesN, opening main sales cursor (LegDetailSaleCursor)... 1 
EXECUTE usp_Message ©zMessage 
OPEN LegDetailSaleCursor 

SELECT ©zMessage = 'PSPriceWASPCalcSalesN, finished opening main sales cursor (LegDetailSaleCursor)...' 
5 EXECUTE usp.Message @zMessage 

FETCH NEXT FROM LegDetailSaleCursor INTO ©yPurchasePKG, 

©yRecMID.gyDelMID.gySalesPKG.gyReceiptgyLDIDPrev.gyGasDay^yPurchasePointTlD.QyStep 

WHILE @@FETCH_STATUS = 0 
BEGIN 

10 r ^ 

* Determine the classification of the 

* purchase deal attached to this sales 

* volume right here... 



15 

7 

EXECUTE uspJGetWasplndicator @yPurchasePKG,@zlncludelnWasp OUTPUT 
IF @zlncludelnWasp- Common' 
BEGIN 

20 SELECT @zDedicatedPurchasePKG=0 

END 

ELSE 

BEGIN 

SELECT @zDedicatedPurchasePKG=@yPurchasePKG 

25 END 

r 



* If sales package has changed OR 
C? * the meter within a sales package 
In 30 * has changed then (amongst other 
T ~ * things) sum up any/all other costs 
y** * for the meter (this ensures that only 
M * one instance of other cost entries 

* are totaled for a given sales deal 
r ' 35 * at a given meter). 

u */ 

^ g SELECT @zOtherCostAmount=0 

; ~ IF (@ySalesPKG<>@zPrevSalePKG) OR (@yRecMID<>@zPrevSaleMID) 

yj 40 BEGIN 

U. SELECT @zPrevSalePKG=@ySalesPKG 

^ SELECT @zPrevSaleMID=@yRecMID 

£=J IF @WhichPricex=0 

BEGIN 

45 SELECT @zOtherCostAmount=ISNULL((SELECT 

SUM(Engine.Amount) FROM Gaslnv.Engine WHERE Gaslnv.PKG=@ySalesPKG 

AND Gaslnv.GasMonth=@GasMonthx AND 
Gaslnv.PriceType=1 AND Engine.TID=Gaslnv.TID AND Gaslnv.Gaslnv_MID=@yRecMID AND Engine.STID<>9),0) 

END 

50 IF @WhichPricex=1 

BEGIN 

SELECT @zOtherCostAmount=ISNULL((SELECT 
SUM(Engine.AmountAct) FROM Gaslnv.Engine WHERE Gaslnv.PKG=@ySalesPKG 

AND Gaslnv.GasMonth=@GasMonthx AND 
55 Gaslnv.PriceType=1 AND Engine.TID=Gaslnv.TID AND Gaslnv.Gaslnv_MID=@yRecMID AND Engine.STID<>9),0) 

END 

END 

r ^ 

60 * Calculate the price and amount for the 

* sales item here (utilizing the Engine 

* calculation). The beginning volume is 

* the amount pulled off the sales association 

* on the database... Break from this 

65 * loop once the first price record has been 

* obtained (for this day)... 

7 

SELECT @zPrice=0 
70 SELECT @zAmount=0 
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SELECT @zVolume=0 

DECLARE EngineCursor CURSOR LOCAL STATIC FORWARD_ONLY FOR 
SELECT 

Engine.PriceOrRateNom, 
5 Engine.PriceOrRateAct 

FROM 

Gaslnv, 
Engine 

WHERE 

1 0 Gaslnv.PKG=@ySalesPKG AND 

Gaslnv.PriceType=1 AND 
EngineTID=Gaslnv.TID AND 
Gaslnv.Gaslnv_MID=@yRecMlD AND 
Engine. Effective<=@yGasDay AND 

1 5 Engine.STID=9 

ORDER BY 

Engine.Effective DESC 

OPEN EngineCursor 

FETCH NEXT FROM EngineCursor INTO @xPriceOrRateNom,@xPriceOrRateAct 
20 IF @@FETCH_STATUS = 0 

BEGIN 

IF @zPrice=0 

BEGIN 

IF @WhichPricex=0 

25 BEGIN 
~! IF ©GasMonthx < '12/01/2000' 

yj BEGIN 
fXJ SELECT 
7sk @zPrice=ROUND(@xPriceOrRateNom p 2) 

%" 30 END 

In ELSE 
f*S BEGIN 

SELECT 

@zPrice=ROUND(@xPriceOrRateNom ( 4) 
\& 35 END 

END 

ELSE 

H BEGIN 

n I IF @GasMonthx < '12/01/2000' 

I * 40 BEGIN 

W SELECT 
H @zPrice=ROUND(@xPriceOrRateAct,2) 

END 

H ELSE 
H= 45 BEGIN 

SELECT 

@zPrice=ROUND(@xPriceOrRateAct,4) 

END 

END 

50 SELECT @zVolume=@yReceipt 

SELECT @zAmount=(@zVolume*@zPrice) 
END 

END 

CLOSE EngineCursor 
55 DEALLOCATE EngineCursor 

r 

* Sum the other cost entry on the 

* amount brought back for the 
60 * production volume amount. The 

* other cost entry will only have a 

* non zero value the first time a 

* sales meter is encountered. Make 

* sure to reset the price entry. 

*/ 

IF @zOtherCostAmount<>0 
BEGIN 

SELECT @zAmount=@zAmount+@zOtherCostAmount 
70 IF (@zAmount<>0) AND (@zVolume<>0) 
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BEGIN 
END 



SELECT @zPrice=ROUND((@zAmount/@zVolume),4) 



END 



10 



15 



20 



25 



30 



35 



40 



45 



50 



55 



60 



65 



70 



* Post a sales entry into the resolved 

* table here,. (LID=0)... This will be 

* the starting point once the routing 

* interative process begins... 



V 

IF ISNULL((SELECT count(*) FROM WASPResolvedRouting WHERE GasMonth=@GasMonthx AND 
RecMID=@yRecMID AND DelMlD=@yDelMID AND 

NomOrActual=@WhichPricex AND lncludelnWasp=@zlncludelnWASP AND 

DedicatedPurchasePKG=@zDedicatedPurchasePKGAND 

ResolvedType='S' AND LID=0 AND EntityCID=@EntityCIDx AND 
KProductlD=@KProductlDx AND KServicelD=@KServicelDx),0) < 1 

BEGIN 

INSERT 

INTO 

WASPResolvedRouting 

(GasMonth.RecMID.DelMID.NomOrActual.Rece^ 
lndudelnWasp,DedicatedPurehaseP^ 

EntityCID,KProductlD,KServicelD ( ResolvedReceiptAmt,ResolvedDeliveredAmt) 

VALUES 

(©GasMonthx.gyRecMID.gyDelMID.gWhichPric^x.QzVolume.O.QzVolume.O.O.QMrnount, 

©zlncludelnWASP.QzDedicatedPurchasePKG.QzPrice.O/N'/S'.O.O, 
@EntityCIDx ( @KProductlDx,@KServicelDx,0,0) 

END 

ELSE 

BEGIN 

IF (@zAmount<>0) AND (@zVolume<>0) 
BEGIN 

UPDATE 

WASPResolvedRouting 



Price=ROUND(((Amount-MgzAmount)/(Receipt-^zVolume)),4) 



SET 



WHERE 



DedicatedPurchasePKG=@zDedicatedPurchasePKGAND 



END 



Receipt=(Receipt+@zVo!ume) ( 

Delivered=(Delivered+@zVolume) p 

Amount=(Amount+@zAmount), 



GasMonth=@GasMonthx AND 
RecMID=@yRecMID AND 
De!MID=@yDelMlD AND 
NomOrActual=@WhichPricex AND 
lncludelnWasp=@zlncludelnWASP AND 



ResolvedType='S' AND 
LID=0 AND 

EntityCID=@EntityCIDx AND 
KProductlD=@KProductlDx AND 
KServicelD=@KServicelDx 



END 



FETCH NEXT FROM LegDetailSaleCursor INTO ©yPurchasePKG, 

©yRed^lD.gyDelMID.QySalesPKG.gyReceiptgyLDlDPrev.gyGasDay.QyPurchasePointTID.igyStep 
END 

CLOSE LegDetailSaleCursor 
DEALLOCATE LegDetailSaleCursor 

r ^ 

* Once all of the sales meters have been 
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inserted then it is time to insert the 
transportation routing leg entries. THese 
are summarized entries. No day-to-day 
cursor processing is required only the 
sum of the unique days. 

Transport legs (type T) and purchase 
points (type 'P') are posted here.. 



DECLARE LegDetailChaseCursor CURSOR LOCAL STATIC FORWARD.ONLY FOR 
SELECT 

LegDetail.PurchasePKG, 

LegDetail.LID, 

LegDetail.RecMID, 

LegDetail.DelMID, 

SUM(LegDetail.Receipt), 

SUM(LegDetail.Delivered), 

SUM(LegDetail.FuelOrOther), 

ROUND(SUM(LegDetail.Receipt*LegDetail.TransportationRate),2), 

ROUND(SUM(LegDetail.Receipt*LegDetail.GatheringRate),2) 

FROM 

Leg Detail 

WHERE 

LegDetail.PurchasePointTID IN (SELECT DISTINCT TID FROM Gaslnv, Package, K WHERE 
Gaslnv.PKG=Package.PKG AND k.kid = Package.KID AND Gaslnv.GasMonth=@GasMonthx AND Gaslnv.DBCR=0 AND Gaslnv.PriceType=1 
and Package.KProductID = ©KProductlDx and Package. KServicelD = ©KServicelDx AND K.EntityCID = ©EntityCIDx) AND 

LegDetail.GasMonth=@GasMonthx AND 

LegDetail.GasDay>=@GasMonthx AND 

LegDetail.GasDay<=@zLastDay AND 

LegDetail.NomOrActuals=@WhichPricex AND 

LegDetail.SalesPKG=0 

GROUP BY 

LegDetail.PurchasePKG, 
LegDetail.LID, 
LegDetail.RecMID, 
LegDetail.DelMID 

SELECT ©zMessage = 'PSPriceWASPCalcSalesN, running query to create transportation legs...' 
EXECUTE usp_Message ©zMessage 
SELECT @zPrevSalePKG=0 
SELECT @zPrevSaleMID=0 

SELECT ©zMessage = 'PSPriceWASPCalcSalesN, opening cursor (LegDetailChaseCursor)...' 
EXECUTE usp_Message ©zMessage 
OPEN LegDetailChaseCursor 

SELECT @zMessage = 'PSPriceWASPCalcSalesN, finished opening cursor (LegDetailChaseCursor)...' 
EXECUTE usp_Message @zMessage 

FETCH NEXT FROM LegDetailChaseCursor INTO ©qPurchasePKG.QqLID.QqRecMID.gqDelMID.gqReceiptQqDelivered.QqFueiOrOther, 

@qTransport,@qGathering 

WHILE @@FETCH_STATUS = 0 
BEGIN 

r 



* Determine the classification of the 

* purchase deal attached to this transort 

* volume right here... 



60 



65 



70 



*/ 

IF (@qPurchasePKG<>@zPrevSalePKG) OR (@QLID<>@zPrevSaleMID) 
BEGIN 

SELECT @zPrevSalePKG=@qPurchasePKG 
SELECT @zPrevSaleMID=@qLID 

END 

EXECUTE usp JGetWasplndicator @qPurchasePKG,@zlndudelnWasp OUTPUT 
IF @zlncludelnWasp='Common' 
BEGIN 

SELECT @zDedicatedPurchasePKG=0 

END 

ELSE 

BEGIN 

SELECT @zDedicatedPurchasePKG=@qPurchasePKG 



-107- 



10 



m 35 



40 



END 

IF @qLID=0 

BEGIN 

SELECT @zType='P' 

END 

ELSE 

BEGIN 

SELECT @zType=T 

END 



* If the leg for this is in the WASP 

* temporary routing table then 

* just update the record with the 
1 5 * totals. Otherwise, insert it and 

* go to the next leg... 

*/ 

SELECT @zAmountWithCosts=((@qGathering-^qTransport)*-1 ) 
20 IF ISNULL((SELECT count(*) FROM WASPResolvedRouting 

WHERE GasMonth=@GasMonthx AND RecMID=@qRecMID AND DelMID=@qDelMID AND 
NomOrActual=@WhichPricex AND lncludelnWasp=@zlncludelnWASP AND 
DedicatedPurchasePKG=@zDedicatedPurchasePKGANDResolvedType=@zType 

AND LID=@qLID AND 

25 EntityCID=@EntityCIDx AND KProductlD=@KProductlDx AND 

KServicelD=@KServicelDx) P 0)<1 

BEGIN 

INSERT 

INTO 

30 WASPResolvedRouting 

(GasMonth ) RecMID ) DelMID ( NomOrActual,Receipt 1 FuelOrOther,Delivered ( 

TransportAmount,GatheringAmount ( Amount,lncludelnWasp p DedicatedPurchasePKG, 

Price.ResolvedReceipt.Resolvedlndicator.ResolvedType.LID.ResolvedDelivered, 

EntityCID.KProductlD.KServicelD.ResolvedReceiptAmt.ResolvedDeliveredAmt) 

VALUES 

(@GasMonthx,@qRecMID,@qDelMID l @^ 



f=* @qTransport,@qGathering p @zAmountWithCosts,@zlncludelnWASP,@zDedicatedPurchasePKG, 

lr* 45 @EntityClDx ) @KProductlDx 1 @KServicelDx,0 1 0) 

END 

ELSE 

BEGIN 

UPDATE 

50 WASPResolvedRouting 

SET 

Receipt=(Receipt-*@qReceipt), 
Delivered=(Delivered+@qDelivered), 
FuelOrOther=(FuelOrOther+@qFuelOrOther) ( 
55 TransportAmount=(TransportAmount->@qTransport), 

GatheringAmount=(GatheringAmount-^qGathering), 
Amount=(Amount+@zAmountWithCosts) 

WHERE 

GasMonth=@GasMonthx AND 
60 RecMID=@qRecMID AND 

DelMID=@qDelMID AND 
NomOrActual=@WhichPricex AND 
lncludelnWasp=@zlncludelnWASP AND 
DedicatedPurchasePKG=@zDedicatedPurchasePKG AND 
65 ResolvedType=@zType AND 

LID=@qLID AND 
EntityCID=@EntityCIDx AND 
KProductlD=@KProductlDx AND 
KServicelD=@KServicelDx 

70 END 
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FETCH NEXT FROM LegDetailChaseCursor INTO 
©qPurchasePKG^qLID.QqRecMlD.gqDelMID.gqReceipt.QqDelivered.QqFuelOrOther, 

@qTransport p @qGathering 

END 

CLOSE LegDetailChaseCursor 

DEALLOCATE LegDetailChaseCursor 

SELECT @zMessage = 'PSPriceWASPCalcSalesN Has Finished...' 

EXECUTE usp.Message @zMessage 

END 



GO 

SET QUOTEDJDENTIFIER OFF SET ANSI.NULLS ON 
GO 

SET QUOTEDJDENTIFIER ON SET ANSLNULLS ON 
GO 

CREATE PROCEDURE usp_PSPriceWASPCIearMonth( 

©GasMonthx DATETIME 
) 

AS 

BEGIN 

SETNOCOUNT ON 

r 

Name: usp.PSPriceWaspClearMonth 

Description: This routine will represents the common 'clean up' routine that 
will purge anything on the database that can be purged. 

The tables cleared include the following: 

GaslnvD (zero volume days for EstAct, Norn, PipelineActuals) 
LegDetail (zero volume routing entries) 

Inputs: 

GasMonthx (gas month to calculate), 
History: 

06/30/1999 JAMIE Original creation 

08/04/1999 JAMIE Modifications to not delete the entries in the 
WASPPurchaseMeterTotals table. This is becuase this table contains 
the information necessary to calculate the margins on a deal. All other 
supporting table entries will be deleted. 

10/12/1999 JAMIE Modifications to procedure to go out and delete any 
daily gas inventory entries that contain no data. Again, since this procedure 
is only executed when the gas month gets marked as completed there 
should be no repurcussions except fewer database records to administer. 
Anything of historical relevance will be retained (ie.. if any volume whatsoever). 

03/30/2000 JAMIE Modifications made in the procedure to remove the zero entry 
routing records from the database (prior deletion of the daily gas inventory 
items should have deleted all of these (based on triggers). However, 
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this is for any/all other residuals. 



08/25/2000 JAMIE Modified in order to remove obsolete cleanup tables 
such as old routing tables/etc. 



*/ 

DECLARE ©zMessage VARCHAR(254) 
DECLARE ©zLastDay DATETIME 

DECLARE @wTID INTEGER 
DECLARE @wGasDay DATETIME 

DECLARE @qLDID INTEGER 

SELECT ©zMessage = ***** STARTED, PSPriceWASPCIearMonth' 

EXECUTE usp_Message ©zMessage 

EXECUTE usp_fl_astDay @GasMonthx,@zLastDay OUTPUT 

f 

* Remove daily inventory items that 

* are now zero... 



*/ 

DECLARE GaslnvDCursor CURSOR LOCAL STATIC FORWARD.ONLY FOR 
SELECT 

Gaslnv.TID, 

GaslnvD.GasDay 

FROM 

Gaslnv, 
GaslnvD 

WHERE 

GaslnvD.TID = Gaslnv.TID AND 
Gaslnv.GasMonth=@GasMonthx AND 
GaslnvD.EstAct = 0 AND 
GaslnvD.Nom = 0AND 
GaslnvD. PipelineActuals = 0 

ORDER BY 

Gaslnv.TID, 
GaslnvD.GasDay 

SELECT ©zMessage = 1 PSPriceWASPCIearMonth, Started removing ZEROd out Inventory Items... 
EXECUTE usp_Message ©zMessage 
OPEN GaslnvDCursor 

FETCH NEXT FROM GaslnvDCursor INTO @wTID, ©wGasDay 
WHILE @@FETCH_STATUS = 0 
BEGIN 

BEGIN TRANSACTION 

DELETE FROM GaslnvD WHERE TID=@wTID AND GasDay=@wGasDay 
COMMIT WORK 

FETCH NEXT FROM GaslnvDCursor INTO ©wTID, ©wGasDay 

END 

CLOSE GaslnvDCursor 
DEALLOCATE GaslnvDCursor 

SELECT ©zMessage = ' PSPriceWASPCIearMonth, Finished removing ZEROd out Inventory Items. 
EXECUTE usp_Message ©zMessage 

r **** ****** ************* ****** 

* Remove any routing items that had 

* no entries within them. 



*/ 

DECLARE LegDetailCursor CURSOR LOCAL STATIC FORWARD.ONLY FOR 
SELECT 

LDID 
FROM 

LegDetail 

WHERE 

GasMonth=@GasMonthx AND 
Receipt=0 AND 
Delivered=OAND 
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Balanced AND 
FuelOrOther=0 

ORDER BY 

PurchasePointTID 

SELECT (gzMessage = ' PSPriceWASPCIearMonth, Started removing ZEROd out Routing (LegDetail) Items.. 
EXECUTE usp_Message @zMessage 
OPEN LegDetailCursor 

FETCH NEXT FROM LegDetailCursor INTO ©qLDID 
WHILE @@FETCH_STATUS = 0 
BEGIN 

BEGIN TRANSACTION 

DELETE FROM LegDetail WHERE LDID=@qLDID 
COMMIT WORK 

FETCH NEXT FROM LegDetailCursor INTO @qLDID 

END 

CLOSE LegDetailCursor 
DEALLOCATE LegDetailCursor 

SELECT ©zMessage = ' PSPriceWASPCIearMonth, Started removing ZEROd out Routing (LegDetail) Items.. 

EXECUTE usp.Message ©zMessage 

SELECT ©zMessage = '**** FINISHED, PSPriceWASPCIearMonth' 

EXECUTE usp.Message ©zMessage 

END 



GO 

SET QUOTEDJDENTIFIER OFF SETANSLNULLS ON 
GO 

SET QUOTEDJDENTIFIER OFF SET ANSI NULLS ON 
GO 

CREATE PROCEDURE usp_PSPriceWASPDivieOutProceedsN( 

©GasMonthx DATETIME, 
©WhichPricex INTEGER, 
@EntityCIDxVARCHAR(12) 
) 

AS 

BEGIN 

r 



Name: usp_PSPriceWASPDivieOutProceeds 
Description: 

This procedure will get executed during the WASP calculation in order 
to credit the financial proceeds (gain or loss) from one deal to another. 

These proceed designations are setup on the package table 
(FinancialPKG and FinancialMID field contains either a deal id 
or a common wasp meter pool point that is to receive the proceeds). 
These fields are mutually exclusive on the deal table. 

The default for all deals is the deal itself (for owning the proceeds). Only 
if the FinancialPKG or FinancialMID field has been entered will it be 
distributed elsewhere. The distribution amount (if any) will be posted 
on the from deal record (either in the FinancialNomAmount or 
FinancialActAmount field, dependant on which price is calculating). 

This procedure works for 3rd party deals only (deal classification rule 
is equal to 'None'). The reason for this is because these are the only 
types of deals where we know the actual margin ('Common' (Wasp) 
and sanctioned sales (Dedicated) are netback calculated deals. 

For all FinancialPKG/MID entries this procedure will: 

1. Calculate the margin (purchase price and purchase meter price). 

2. Reduce the purchase meter amounts by the amount calculated. 

3. Post the dollar amount to the proceed purchase meter(s) based on their respective 
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45 



volume weightings to the deal. 
Inputs: 

GasMonthx - Gas Month 

WhichPricex - 0=Nominations, 1=Actuals 

EntityCIDx - owning company/entity 

History: 

07/27/1999 JAMIE Original Creation. 



10/13/1999 JAMIE Modified to cast the distribution amounts to decima!(18,4). 
This is because of bug receiving correct amount to distrubute when dividing 
15 two integers. 

03/30/2000 JAMIE Modified the program to not use the 'PackageLinks' 
table but to use the FinancialPKG field stored on the deal table. This 
was done as part of the integration with linking and the new route 
20 process. 

05/24/2000 JAMIE Modified to include the owning company/entity. 

07/28/2000 JAMIE Modified in order to post the updates of what is 
25 being distributed back to the Package table (for the 'from* deal) and 

Q then post the amounts to the WASP Purchase Meter table (for deals) 

. & f\ or WASP Legs for meters. This change was done in order to 

2? facilitate the reordering of the calculations. 

30 08/07/2000 JAMIE Modified so that even if diving to a specific deal IF 

that deal is a wasp deal then all deals that share the same original 
purchase point meters as the deal being divied to (in the 'Common' pool) 
B will share in the divie. 

jHT 35 08/18/2000 JAMIE Modified so that if diving to a specific deal then the 

amount will go to the WASPResolvedRouting table versus the obsolete 
= WASPPurchaseMeterTable. 



40 7 

r 



* Declare all variables and cursors 

* that are needed by this process. 



*/ 

DECLARE ©zMessage VARCHAR(254) 
DECLARE ©zLastDay DATETIME 
DECLARE ©zPurchasePrice DECIMAL(19,6) 

50 DECLARE ©zlncludelnWasp VARCHAR(10) 

DECLARE ©zTotalVolume INTEGER 
DECLARE ©zGrandTotalDistributed DECIMAL(19,2) 
DECLARE ©zTempVolPercent DEClMAL(19 t 4) 
DECLARE ©zAmountToDistribute DECIMAL(19,2) 

55 DECLARE ©zMarginPrice DECIMAL(18,4) 

DECLARE ©zMarginAmt DECIMAL(19,2) 
DECLARE ©zFoundDedicated VARCHAR(1) 
DECLARE ©zSumofFBOPKGCreditMeters INTEGER 
DECLARE ©zAmountToCredit DECIMAL(19,2) 

60 DECLARE ©zSumofFBOPKGMeters INTEGER 

DECLARE @yPKG INTEGER 
DECLARE ©yFinancialPKG INTEGER 
DECLARE ©yKProductID INTEGER 
65 DECLARE ©yKServicelD INTEGER 

DECLARE ©yFinancialMID INTEGER 

DECLARE ©yWASPReceipt DECIMAL(19,2) 
DECLARE ©yWASPAmount DECIMAL(19 ( 2) 
70 DECLARE ©yWASPPrice DECIMAL(19,6) 
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DECLARE ©yWASPResolvedID INTEGER 



DECLARE ©yWASPCreditReceipt DECIMAL(19,2) 
DECLARE ©yWASPCreditAmount DECJMAL(19,2) 
DECLARE ©yWASPCreditPrice DECIMAL(19,2) 
DECLARE ©yWASPCreditResolvedID INTEGER 

DECLARE ©qDelivered DECIMAL(19,2) 
DECLARE @qAmountDECIMAL(19 P 2) 
DECLARE ©qPrice DECIMAL(19 t 6) 
DECLARE ©qResolvedID INTEGER 

SELECT ©zMessage = 'PSPriceWASPDivieOutProceedsN, ***STARTED*** 

EXECUTE usp_Message @zMessage 

EXECUTE uspJLastDay @GasMonthx,@zLastDay OUTPUT 

r ^ llkllllllllillkk]Lklill 

* At this point we want to loop 

* through ail of the packages 

* (deals) on the system that had 

* requested that the proceeds 
*be divied to other deals. 

7 

DECLARE ProceedsCursor CURSOR LOCAL STATIC FORWARD.ONLY FOR 
SELECT 

PKG, 

FinancialPKG, 

KProductID, 

KServicelD, 

FinancialMID 

FROM 

Package, 
K 

WHERE 

(K.KlD=Package.KID) AND 

(K.EntityCID=@EntityCIDx)AND 

(StartDate BETWEEN ©GasMonthx AND ©zLastDay) AND 

(((FinancialPKG IS NOT NULL) AND (FinancialPKG<>0)) OR ((FinancialMID IS NOT NULL) AND 

(FinancialMID<>0))) 

ORDER BY 

PKG 

OPEN ProceedsCursor 

FETCH NEXT FROM ProceedsCursor INTO @yPKG,@yFinancia!PKG,@yKProductlD,@yKServicelD ( @yFinancialMID 
WHILE @@FETCH_STATUS = 0 
BEGIN 

BEGIN TRANSACTION 

SELECT @zMessage = 'PSPriceWASPDivieOutProceedsN, Proceeds divied from deal...' + CAST(@yPKG as 

VARCHAR(12)) 

EXECUTE usp_Message ©zMessage 

r 



* Get the agreed upon purchase 

* price from the engine for the 

* 'from' purchase deal. The total 

* volume across all days is also 

* obtained here (for all meters). 

* Base the price on the weighted 

* averages for all entries within 

* the Engine table. 

* This yields the single weighted 

* average cost across all wells 

* and days. 

* This price should be the price 

* that was found PRIOR to diving 
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* out any adjusments. 



V 

IF @WhichPricex=0 
5 BEGIN 

SELECT @zPurchasePrice=ROUND(ISNULL((SELECT 
SUM(Engine.Amount)/SUM(Engine.Volume) FROM Engine.Gaslnv 

WHERE 

(Gaslnv.GasMonth=@GasMonthx AND Gaslnv.PKG=@yPKG) AND (Engine.TID=Gaslnv.TID) AND (Engine,STID=8) AND 
1 0 Engine.Amount>0 
and Engine.Volume>0),0),4) 

SELECT @zTotalVolume=ISNULL((SELECT SUM(Engine.Volume) FROM Engine.Gaslnv 
WHERE (Gaslnv.GasMonth=@GasMonthx AND Gaslnv.PKG=@yPKG) AND 

1 5 (Engine.TID=Gaslnv.TID) AND (Engine.STID=8) AND 

Engine.Amount>0 

and Engine. Volume>0),0) 

END 

IF @WhichPricex=1 
20 BEGIN 

SELECT @zPurchasePrice=ROUND(ISNULL((SELECT 
SUM(Engine.AmountAct)/SUM(Engine.VolumeAct) FROM Engine.Gaslnv 

WHERE 

(Gaslnv.GasMonth=@GasMonthx AND Gaslnv.PKG=@yPKG) AND (Engine.TID=Gaslnv.TID) AND (Engine.STID=8) AND 
25 Engine.AmountAct>0 
and Engine.VolumeAct>0),0),4) 

SELECT @zTotalVolume=ISNULL((SELECT SUM(Engine.VolumeAct) FROM Engine.Gaslnv 
WHERE (Gaslnv.GasMonth=@GasMonthx AND Gaslnv.PKG=@yPKG) AND 

30 (Engine.TID=Gaslnv.TID) AND (Engine.STID=8) AND 

Engine.AmountAct>0 

and Engine. VolumeAct>0),0) 

END 

I* 



35 



45 



* Only continue if the purchase 

* price (average) for this deal 

* could be calculated (ie.. there 

* was a volume and there was 
40 * a price entry. 



* Now loop through each of the 

* meters to determine how much 

* to reduce each meter by... 



*/ 

SELECT @zGrandTotalDistributed=0 
IF (@zPurchasePrice>0) 
BEGIN 

50 IF @zTotalVolume<>0 

BEGIN 

I* This cursor is for determining proceed amounts*/ 

55 DECLARE WASPResolvedRoutingDebitCursor CURSOR LOCAL 

STATIC FORWARD ONLY FOR 

SELECT 

receipt, 
amount, 

60 price, 

ResolvedID 
FROM 

WASPResolvedRouting 

WHERE 

65 GasMonth=@GasMonthx AND 



AND 



DedicatedPurchasePKG=@yPKG 
NomOrActual=@WhichPricex 



AND 

70 E ntityC I D=@ E ntityC I Dx AND 
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in 



\ y 



10 



15 



20 



25 



30 



35 



40 



45 
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55 



@yWASPReceipt,@yWASPAmount, 

@yWASPPrice,@yWASPResolvediD 

@zPurchasePrice),4) 

@2MarginAmt=ROUND((@zMarginPrice # @zTotalVolume),2) 



KProductlD=@yKProductlD AND 
KServicelD=@yKServicelD AND 
ResolvedType- P' AND 
LID=0 AND 
RecMID=DelMID 
OPENWASPResolvedRoutingDebitCursor 
FETCH NEXT FROM WASPResolvedRoutingDebitCursor INTO 



WHILE @@FETCH_STATUS = 0 
BEGIN 

SELECT @zMarginPrice=ROUND((@yWASPPrice- 
SELECT 

IF @yWaspReceipt>0 
BEGIN 



@zTempVolPercent=ROUND((@yWaspReceipt/@2TotalVolume),4) 

@zAmountToDistribute=ROUND((@zTempVolPercent*@2MarginAmt),2) 

@zGrandTotalDistributed=@zGrandTotalDistributed-^zAmountToDistribute 

WASPResolvedRouting 

Amount=AmounH{@zAmountToDistribute*-1) 

ResolvedlD=@yWASPResolvedlD 

WASPResolvedRouting 

Price=(Amount/Receipt) 

ResolvediD=@yWASPResolvedlD AND 

Receipt<>0 AND 

AmountoO 

INTO @yWASPReceipt,@yWASPAmount, 

@yWASPPrice,@yWASPResolvedlD 



SELECT 
SELECT 
SELECT 
UPDATE 



UPDATE 



SET 



WHERE 



SET 



WHERE 



END 

FETCH NEXT FROM WASPResolvedRoutingDebitCursor 



END 



END 



CLOSE WASPResolvedRouting DebitCursor 
DEALLOCATE WASPResolvedRoutingDebitCursor 



END 



60 



65 



70 



* At this point, if there has been any 

* proceeds distributed from the 

* purchase deal then go and distribute 

* the amount back to the deal where 

* that is receiving credit. This is 

* based on the volume weighting 

* distribution at the target 'to' meter. 

* The field zGrandTotalDistributed contains 

* the total dollar amount to be credited 

* the the meters (based on volume 

* weighting. 



-115- 



7 

IF @zGrandTotalDistributed<>0 
BEGIN 

r ^ ^ 

* Post the 'from' deal with the 

* appropriate distributed amount 

* This is the total amount across 

* the entire deal and is stored on 

* the deal record to provide an 

* audit of how much was diverted. 



7 

IF @WhichPricex=0 
BEGIN 

UPDATE 

Package 
SET 

FinancialNomAmount=@zGrandTotalDistributed 

WHERE 

PKG=@yPKG 

END 

IF @WhichPricex=1 
BEGIN 

UPDATE 

Package 
SET 

FinancialActAmount=@zGrandTotalDistributed 

WHERE 

PKG=@yPKG 

END 

r 

* If diving to another deal then 

* perform this.... Adjustments are 

* made to the WASPResolved Routing 

* table. There is no need to post 

* adjustments to the Engine table 

* since the target deals have either 

* not yet calculated (dedicated) or 

* the Engine price is fixed (3rd 

y^ } iiitiiiiii i 

7 

IF (@yFinancialPKG IS NOT NULL) AND (@yFinancialPKG<>0) 
BEGIN 

r 



* Determine if the target deal is 

* a wasp deal or a 3rd party or 

* sanctioned sale deal... If it is a 

* wasp deal then the originating 

* meters in the common pool 

* will get the credit. 

7 

EXECUTE uspJGetWasplndicator @yFinancialPKG,@zlncludelnWasp OUTPUT 

r 

* Sum totals across all meters on 

* the target deal... 



7 

IF @WhichPricex=0 

BEGIN 
SELECT 

@zSumofFBOPKGCreditMeters=ISNULL((SELECT SUM(inventory.Nom) FROM gaslnv AS inventory 
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20 



inventory.PKG=@yFinancialPKG AND inventory,GasMonth=@GasMonthx AND inventory.DBCR=0 AND inventory. PriceType=1),0) 

END 

IF @WhichPricex=1 

BEGIN 
SELECT 

@zSumofFBOPKGCreditMeters=ISNULL((SELECT SUM(inventory.PipelineActuals) FROM gaslnv AS inventory 

inventory.PKG=@yFinancialPKG AND inventory.GasMonth=@GasMonthx AND inventory.DBCR=0 AND inventory. PriceType=1) P 0) 

END 

r 



WHERE 



WHERE 



* If there is some sort of volume 

* then post it proportionately. 



*/ 

IF @zSumofFBOPKGCreditMeters<>0 
BEGIN 

r 



* if not a wasp deal to post the 

* credit to then... 



3 Fi 



hi 



25 



30 



35 



40 



45 



50 



55 



60 



65 



70 



IF @zlncludelnWasp <> 'Common' 
BEGIN 



posting proceeds to a dedicated deal point*/ 

WASPResolvedRoutingCreditDedicatedCursor CURSOR LOCAL STATIC FORWARD_ONLY FOR 

receipt, 
amount, 
price, 

ResolvedlD 
FROM 



WASPResolvedRouting 



WHERE 



GasMonth=@GasMonthx AND 
DedicatedPurchasePKG=@yFinancialPKG AND 
NomOrActual=@WhichPricex AND 
receipt>0 AND 
ResolvedType- P' AND 
LID=0 AND 
RecMID=DelMID 
WASPResolvedRoutingCreditDedicatedCursor 

WASPResolvedRoutingCreditDedicatedCursor INTO ©yWASPCreditReceipt 

@yWASPCreditAmount,@yWASPCreditPrice,@yWASPCreditResolvedlD 
@@FETCH_STATUS = 0 



/* This cursor is for 
DECLARE 

SELECT 



OPEN 

FETCH NEXT FROM 



WHILE 



BEGIN 
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SELECT @zTempVolPercent=ROUND((@yWaspCreditReceipt/@zSumofFBOPKGCreditMeters) ( 4) 
SELECT @zAmountToCredit=ROUND((@zTempVolPercent*@zGrandTota!Distributed) J 2) 
IF @zAmountToCredit<>0 
BEGIN 

UPDATE 

WASPResolvedRouting 
SET 

Amou nt=(Amount-K5)zAmou ntToCred it) 

WHERE 

ResolvedlD=@yWASPCreditResolvedlD 

UPDATE 

WASPResolvedRouting 
SET 

Price=(Amount/Receipt) 



WHERE 



ResolvedlD=@yWASPCreditResolvedlDAND 

Amount<>0 AND 

Receipt<>0 



END 



FETCH NEXT FROM WASPResolvedRoutingCreditDedicatedCursor INTO @yWASPCreditReceipt, 
@yWASPCreditAmount,@yWASPCreditPrice,@yWASPCreditResolvedlD 

WASPResolvedRouting CreditDedicatedCursor 
WASPResolvedRouting CreditDedicatedCursor 



END 



* if wasp deal to post the 

* credit to then... 



IF ©zlncludelnWasp-Common' 
BEGIN 



posting proceeds to a common meter purchase point*/ 

WASPResolvedRoutingCreditWASPCursor CURSOR LOCAL STATIC FORWARD_ONLY FOR 

wp. receipt, 
wp.amount, 
wp. price, 



END 

CLOSE 
DEALLOCATE 



I* This cursor is for 
DECLARE 

SELECT 
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P 

rr 35 



wp.ResolvedID 
FROM 

5 

WASPResolvedRouting AS wp, 
Gaslnv AS g 

10 WHERE 

g.GasMonth=@GasMonthx AND 
g.PKG=@yFinancia!PKGAND 

15 

g.Gaslnv_MID=wp.RecMID AND 
wp.GasMonth=@GasMonthx AND 
20 wp.DedicatedPurchasePKG=0 AND 

wpJncludelnWasp-Common' AND 
wp.NomOrActual=@WhichPricex AND 

25 

wp.receipt>0 AND 
wp.EntityClD=@EntityCIDx AND 
30 wp.KProductlD=@yKProductlD AND 

wp.KServicelD=@yKSen/icelD AND 
wp.ResolvedType- P' AND 
wp.LID=0 AND 
wp.RecMID=DelMID 



40 WASPResolvedRoutingCreditWASPCursor 



50 



OPEN 



|jj FETCH NEXT FROM 

^ WASPResolvedRoutingCreditWASPCursor INTO ©yWASPCreditReceipt, 

□ @yWASPCreditAmount,@yWASPCreditPrice,@yWASPCreditResolvedlD 

U 45 WHILE 

@@FETCH_STATUS = 0 

BEGIN 



SELECT @zTempVolPercent=ROUND((@yWaspCreditReceipt/@zSumofFBOPKGCreditMeters),4) 
SELECT @zAmountToCredit=ROUND((@zTempVoIPercent*@zGrandTotalDistributed) ( 2) 
IF @zAmountToCredit<>0 



55 BEGIN 

UPDATE 

60 

65 WHERE 

UPDATE 



WASPResolvedRouting 
SET 

Amount=(Amount+@zAmountToCredit) 

ResolvedlD=@yWASPCreditResolvedlD 
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WHERE 



WASPResotvedRouting 
SET 

Price=(Amount/Receipt) 

ResolvedlD=@yWASPCreditResolvedlDAND 

Amount<>0 AND 

Receipt<>0 



END 



FETCH NEXT FROM WASPResolvedRoutingCreditWASPCursor INTO ©yWASPCreditReceipt, 
@yWASPCreditAmount p @yWASPCreditPrice,@yWASPCreditResolvedlD 

WASPResolvedRoutingCreditWASPCursor 
WASPResolvedRoutingCreditWASPCursor 



END 

CLOSE 
DEALLOCATE 



END 



END 



END 



* If diving to the WASP pool then 

* the total distributed is posted 

* proportionately on each leg that 

* contains this meter in the 

* 'Common' pool. 

7 

IF (@yFinancialMID IS NOT NULL) AND (@yFinancialMID<>0) 
BEGIN 

r 



* Sum totals across all legs that 

* have the same meter in the 

* 'Common' pool for the month. 



FROM WaspResolvedRouting 

GasMonth=@GasMonthx AND LID<>0 AND 

NomOrActual=@WhichPricex AND lncludelnWasp='Common' AND 
EntityClD=@EntityCIDx AND KProdudlD=@yKProductlD AND 
KServicelD=@yKServicelD AND DelMID=@yFinancialMID),0) 

r 



v 

SELECT @zSumofFBOPKGCreditMeters=ISNULL((SELECT SUM(Delivered) 

WHERE 



* If there is some sort of volume 

* then post it proportionately to 

* each of the legs in the WASP 

* resolved routing table. 



7 

IF @zSumofFBOPKGCreditMeters<>0 
BEGIN 



pool (non entry point)*/ 



P This cursor is for posting proceeds to a wasp 
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WASPResolvedRoutingCreditCursor CURSOR LOCAL STATIC FORWARD.ONLY FOR 



DECLARE 



SELECT 



AND 



delivered, 

amount, 

price, 

ResolvedID 
FROM 



WHERE 



WASPResolvedRouting 

GasMonth=@GasMonthx AND 
NomOrActual=@WhichPricex AND 
EntityCID=@EntityCIDx AND 
KProductlD=@yKProductlD AND 
KServicelD=@yKServicelD AND 
DelMID=@yFinancialMID AND 

IncludelnWasp- Common' AND 
delivered>0 

OPEN WASPResolvedRoutingCreditCursor 
FETCH NEXT FROM 

WASPResolvedRoutingCreditCursor INTO @qDelivered p @qAmount,@qPrice,@qResolvedlD 

WHILE @@FETCH_STATUS = 0 
BEGIN 

r 



LID<>0 



percent to post 



* Determine the 

* here... 



45 



50 



55 



60 



65 



@zTempVolPercent=ROUND((@qDelivered/@zSumofFBOPKGCreditMeters),4) 
@2AmountToCredit=ROUND((@2TempVolPercent*@zGrandTotalDistributed),2) 
@zAmountToCredit<>0 

UPDATE 

WASPResolvedRouting 
SET 

Amount=(Amount+@zAmountToCredit) 

WHERE 

ResolvedlD=@qResolvedlD 
WASPResolvedRoutingCreditCursor INTO @qDelivered,@qAmount, 



SELECT 
SELECT 
IF 



BEGIN 



END 

FETCH NEXT FROM 



@qPrice,@qResolvedlD 



END 

CLOSE WASPResolvedRoutingCreditCursor 
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DEALLOCATE 

WASPResolvedRoutingCreditCursor 

END 

END 

5 END 
COMMIT WORK 

FETCH NEXT FROM ProceedsCursor INTO @yPKG,@yFinancialPKG ( @yKProductlD f @yKServicelD,@yFinancialMID 

END 

CLOSE ProceedsCursor 
1 0 DEALLOCATE ProceedsCursor 

SELECT ©zMessage = 'PSPriceWASPDivieOutProceedsN, "'FINISHED**" 

EXECUTE usp.Message @zMessage 

END 

15 



20 



25 GO 

~ SET QUOTEDJDENTIFIER OFF SET ANSI.NULLS ON 

U GO 

^ SET QUOTEDJDENTIFIER ON SET ANSI.NULLS ON 

^ 30 GO 

ill 

i q CREATE PROCEDURE usp fGetCatclndex( 

« @TIDx INTEGER, 

^ ©NomOrActualx INTEGER, 

M* 35 @EntityCIDxVARCHAR(12) ( 

L. ©KProductlDx INTEGER, 

r " ©KServicelDx INTEGER, 

£ ©GasMonthx DATETIME, 

ti ©rReturnValue DECIMAL(19,6) OUTPUT 

F 40 ) 

- - AS 

yj BEGIN 

Q 45 Name: uspJGetCalclndex 

Description: This is the main process for finding the actual price that was 
calculated for a WASP purchase deal. The WASPResolvedRouting table 
contains all of the prices for WASP purchases. 



50 



55 



60 



An attempt should first be made to see if the price can be resolved by reading 
for a 'Dedicated' wasp pool (sanctioned sales/purchases are more or less 
dedicated). The purchase deal id must match the dedicatedpurchasepkg field 
on the WASPResolvedRouting. 

If the specific package cannot be found then the purchase meter will be used 
(ie.. 'Common' wasp pool). 

Inputs: 



TIDx - Unique Key to gas inventory record (Gaslnv) 
NomOrActualx - 0=Nominations, ^Actualizations 
EntityCIDx- owner 
KProductlDx - product id 
65 KServicelDx - service 

GasMonthx - Current gas month 
rReturnValue - OUTPUT return value 



70 



History: 
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06/29/1999 JAMIE Modified from original creation 

(date of original creation ?) to support WASP calc changes V2.20. 



06/22/2000 JAMIE Modified to get wasp prices based on entity, 
product and service. 

08/18/2000 JAMIE Modified to get the wasp prices off the WASPResolvedRouting 
table versus the obsolete WASPPurchaseMeterTable. 

1 1/07/2000 JAMIE Modifications to convert from Watcom-SQL to 
Transact-SQL. 

7 

r ^ ^ ^ 

* Declare all variables and cursors 

* that are needed by this process. 

V 

DECLARE @ymid INTEGER 
DECLARE @ypkg INTEGER 
DECLARE ©ygasmonth DATETIME 
DECLARE @yWorkValue DECIMAL(19 t 6) 
DECLARE ©message VARCHAR(255) 
/* 



* Initialize key fields and then get 

* the meter and deal information 

* off the gas inventory table. 



V 

SELECT @rReturnValue=0 
SELECT 

@ymid=gasinv_mid, 
@ypkg=pkg, 
@ygasmonth=gasmonth 
FROM 

gasinv 

WHERE 

tid=@tidx 

r 



* Now try and read the price off the 

* WASPResolvedRouting with 

* an assumption that it could be a 

* sanctioned sale deal. 

V 

r 

* If price is a dedicated purchase 

* price then get that number. Otherwise, 

* the the price from the WASP pool. 



•/ 

IF ((SELECT countH FROM WASPResolvedRouting 

WHERE DedicatedPurchasePKG=@ypkg AND GasMonth=@ygasmonth AND lncludelnWasp='Dedicated' AND 
NomOrActual=@NomOrActualx AND RecMlD=@ymid 

AND DelMID=@ymid AND ResolvedType='P' AND LID=0 AND Entity C I D=@E n tityCI Dx AND 
KProductlD=@KProductlDx AND KServicelD=@KServicelDx) > 0) 

BEGIN 

SELECT @yWorkValue=Price FROM WASPResolvedRouting 

WHERE DedicatedPurchasePKG=@ypkg AND GasMonth=@ygasmonth AND I ncludelnWasp- Dedicated' 
AND NomOrActual=@NomOrActualx AND RecMID=@ymid 

AND DelMID=@ymid AND ResolvedType='P' AND LID=0 AND EntityCID=@EntityCIDx AND 
KProductlD=@KProductlDx AND KServicelD=@KServicelDx 
END 

ELSE 

BEGIN 
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SELECT @yWorkValue=Price FROM WASPResolvedRouting 

WHERE RecMID=@ymid AND DelMlD=@ymid AND LID=0 AND ResolvedType='P' 
AND gasmonth=@ygasmonth AND IncludelnWasp- Common' AND 
NomOrActual=@NomOrActuatx AND Entity C I D =@E ntity C I Dx 

AND KProductlD=@KProductlDx AND KServicelD=@KServicelDx 

END 

r 



* If some sort of price was found then 

* return with it.. Otherwise zeros 

* are returned (no price calculated). 



7 

r 

SELECT ©message = 'WASP Price ' + 

CAST(@yWorkValue AS VARCHAR(12)) + 
' for meter id ' + 

CAST(@ymid AS VARCHAR(12)) 
EXECUTE usp_message @message 
7 

IF ©yWorkValue IS NOT NULL 
BEGIN 

SELECT @rReturnValue=@yWorkValue 

END 

END 



GO 

SET QUOTEDJDENTIFIER OFF SETANSLNULLS ON 
GO 



ADDITIONAL FEATURES 

The present invention has been disclosed, illustrated, and described in 
relation to a client-server application that facilitates pricing and distribution of 
fuel to a customer. Although centralized data storage and manipulation is 
preferred in regard to the version of the system that has been provided, the 
inventors contemplate other applications and enhancements that certainly are 
within the scope of the present invention. For example, the present invention 
relies on data inputs and feeds from a variety of entities such as producers, 
transporters, etc. Although such data inputs are often entered manually into 
the systems provided by the present invention, such data inputs could be 
automatically delivered and stored within data store 106 (FIG. 2). For example, 
transporters controlling actual meters along a gas pipeline, for example, could 
be outfitted with remote sensors and transmitters that provide shipment volume, 
etc. details directly to the systems provided by the present invention. Moreover, 
data inputs such as indexing datum used to drive pricing, etc. may be similarly 
obtained. And, since such data inputs can come from a variety of sources, 
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modern communications technologies such as the Internet, wireless 
technologies, etc. could all be used to couple an operator of the systems and 
methods provided by the present invention with such sources. Accordingly, the 
present invention is not limited to any particular data retrieval system, topology, 
method, or paradigm. Those skilled in the art will be immediately able to adapt 
and modify the underlying data collection capabilities of the systems and 
methods provided by the present invention to incorporate such new and modern 
technologies and techniques. 

Finally, it should be noted that the present invention contemplates and 
provides for an elaborate reporting capability as provided within the software 
contained on the attached compact disc. Those skilled in the art of computer 
programming and those familiar with fuel deal management will immediately 
understand that any number of report may be prepared to suit and satisfy 
management requirements. The database tables maintained by the present 
invention certainly support all types of relational type queries that such reports 
may require. 

Thus, having fully described the present invention by way of example 
with reference to the attached drawing figures, it will be readily appreciated that 
many changes and modifications may be made to the invention and to any of 
the exemplary embodiments shown and/or described herein without departing 
from the spirit or scope of the invention which is defined in the appended 
claims. 
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